Upgrading MVC apps done with VS 2010 has been the biggest issue for me. I have an application that I use to run various websites and I maintain and develop this application separetely then upgrade the sites based on it. A lot of things might change during development of a new version - new Views, new Controllers, stuff added into JS files, updated stylesheets etc.
I've searched around the web but nothing useful came up besides this Haack's article but no source code is available.
I also tried making a Nuget package for the entire MVC app and while this works, it doesn't package up the resource files (an issue within Nuget itself) and my apps rely on those so until this is fixed I cannot use this method.
I checked how others do it and this pretty much summarizes Umbraco's way and it's the same painful way of a dozen of steps like I do it now.
Do you have any good advice on it?
You don't specify the target OS, but I create native packages, i.e. .deb for Ubuntu servers.
However this still means you need to specify all files, manage configuration, upgrade database schemes. But if you test this on a CI server it becomes more reliable, and you can do it iteratively. This is all part of good deployment practice. I can recommend the Continuous Delivery book.
Related
In PHP, you can just log in to the FTP and see all of the files. I notice in VB ASP.NET MVC when I publish a site it doesn't include the controllers or models. Rather, it seems to compile them into DLLs. How can the files be modified with out access to the originals? Would a developer have to publish the files in a separate directory and then the other developer pull them down and open the project in visual studio?
Keep your SourceCode in a Version Control System like SVN /GIT /TFS etc.. Whenever you want to make an update , Get the specific version you want to update and make update to that.
Having a Version control gives you so many advantages
1) Collaborative working. Many members of a team can work on same code base without overwriting conflict
2) Restore to a Previous Version : Something wrong with the current production move ?. Just get the Previous version (Label) which is working fine (and was running in prod) and rollback to that till you fix the issue.
Keeping the Previous versions of code will save a lot of time in a Programmers / Team's life.
This SO question has good points about why we should use version control.
Version control is not only for Teams. Individual developers can keep their code in Version controls and sleep nicely
Btw, Your MVC project's Model classes and Controllers classes are compiled into the DLL files.
I've seen a lot of companies that work with Visual Studio implement Visual Source Safe.
information can be found here http://msdn.microsoft.com/en-us/library/3h0544kx%28v=vs.80%29.aspx
otherwise it's pretty much what Shyju said.
In a professional environment, there is a very clear distinction between editing source code, and deploying to production. You seem to make no distinction.
Usually developers make changes under careful control using a source control system like SVN.
Build & deployment is then done separately by a dedicated team member. Developers do not touch the production servers willy-nilly.
How can the files be modified with out access to the originals?
I don't understand. If you want developers to have full access to the production environment, why not give them full access to the source code as well? In your PHP example this is a given.
At work we have about 30 legacy sites which run from a common set of code, currently these sites are in cold fusion. For this common code we have one project, then in IIS we set up a virtual directory to include the common code into each site. This works great, as changes to core logic can be made in one place, and its replicated through all the sites. And as all of our sites are hosted on the same servers, we can also just deploy the common code and all the live sites are updated, we don't need to release every site.
However we are in the process of re-writing our sites and core code into c# and asp.net MVC 3. Its going well, except when we update the core code, we are currently copying the dlls into each site, recompiling, then releasing each site.
This is fine while we only have a couple of sites re-built with the core code, but is going to be very painful when all 30 of our sites have been re-built in .net.
Does anyone have any ideas of how to easily use and delpoy common code without having to copy the dlls to every site?
So far we've tried:
- using a virtual directory of the dlls (doesn't work as site code needs to be re-compiled, and IIS doesn't seem to like it on .net sites anyway)
- deploying our common dlls to the GAC - this is an issue as the third party libraries (eg nHibernate) aren't signed, so can't add them to the GAC too.
Thanks
Saan
The easiest way is to automate your update procedure.
But if you want to rid of copying at all then you can try thing named "codebase".
Here is description of "How the Runtime Locates Assemblies" and details of "Locating the Assembly through Codebases or Probing" http://msdn.microsoft.com/en-us/library/15hyw9x3(v=vs.71).aspx
Interesting.
I also saw in the next .net relase they have http://www.asp.net/vnext/whats-new#_Toc_perf_3 “Sharing Common Assemblies”
This will give us a couple of options to investigate thanks.
The project is developed using ASP.NET MVC framework and heavily relies on .NET 3.5.
What would be the best solution to allow a web designer, who is using OSX, to develop the site's UI? Basically he would just need to edit the aspx, css and js files, but also run the web application locally.
I've thought of some possibilites:
Install parallels/vmware/bootcamp and set up everything as you would for windows. Bad: it would be slow, OSX user doesn't like working in windows
Set up Mono and run the webapp on that. Use whatever tool you want for editing the front end files. Bad: does mono support MVC framework, .NET 3.5 and database connections? Unfamiliar platform, so possibly a lot of work setting it up, if it even will work.
Run the site on a separate server, and edit the front end files via network drive. Bad: our development server is so slow that seeing the changes takes too long...
Do you have other ideas or comments for these options?
Thanks!
You could try using a virtual machine. VirtualBox is a free one and is quite simple to setup. The only downside is that you need your own copy of Windows...
What you really need to do is have your web designer mock up the pages in static HTML, CSS, and JavaScript first (in their environment of preference.) Once that's done, adapting the markup to the ASP.NET project should be easily doable by yourself or the designer on a Windows machine (or virtual machine, your preference).
The MVC framework is part of Mono. Ares Technica has an article about the MVC framework and running it on Mono.
While it seems that some people were able to hack the framework to work on Mono back in March and April of this year, Microsoft has since released the MVCframework as open source and it is now fully supported by Mono as of the 2.4.2 release.
Here is a link to the most recent Mono releases along with Virtual Machine images that already been pre-configured to give you the best development experience.
Good luck with your project and hope this helps some.
I'd like to create an application using ASP.NET MVC, that should run under mono 2.4 (compiling will be done on a Windows box). Has anyone getting luck with this? Here is what I've already tried:
ASP.NET MVC on mono without any persistence model support, and using nhaml as the view engine
S#aml architecture, which is a quite good framework imho, but it depends too much on stuff, that are not working good under mono (like windsor)
The first part worked fine, I didn't encounter any major problems. But I couldn't get the second part working. It seems it's dependency on Castle.Windsor breaks the whole mono support (but there might be other parts too).
Therefore I decided to create an alternative framework, that borrows some of the ideas of s#arp-architecture, but designed to be working under mono (and if I'm able to do this I'll release it for the community of course). The controller and view part is working fine (not much magic here though, they have been always working), but I have some questions before I start job on the persistence part:
What NHibernate versions are working under mono? I've heard 1.2 is working fine. Does 2.0.1/2.1 beta work under mono?
Does Fluent.NHibernate and NHibernate.Linq work under mono? (for the latter it seems it needs some dependcies that aren't avaialable in mono)
Are there any good alternatives for persistence support to NHibernate under mono?
Alternative questions:
Are there any frameworks that have mono+persistence+asp.net mvc support already or am I the first one to think about this?
If you have already done this: what are your opinions on stability/usability?
Thanks for the answers
EDIT: Updated the framework to support ASP.NET MVC 2: http://shaml.sztupy.hu/
I am using mono 2.4 to run a asp.net mvc app + windows service.
Compatibility is very good. There are some bugs and differences than with windows but once you learn what they are it gets easier (there can be pain at the start!)
I am using NHibernate (2.1) FluentNhibernate, StructureMap, NBehave, Moq and open id lib and they all just seem to work as expected.
As for stability, since I have ironed out the major bugs in my code I haven't had any problems.
Usability, well it is a completely different platform so you need to come to it with an open mind and be prepared to leave behind the windows way.. the good news is that once you do that things get easier. Apache is a lot nicer than IIS and configuring and managing a linux box is just easier than windows.
I am pretty glad I choose mono.. sorry this is starting to sound like a PR drive - but I am just really happy with it!!
Okay. I started on a new project that incorporates the best from S#arp Architecture with stuff, that work on mono. Instead of T4Toolkit it uses a ruby script to do the generation job, just as with rails or merb.
To use install the shaml gem from github:
gem install shaml
Then create a new application:
shaml generate app AppName
And create resources:
shaml generate resource NewRes "name:string;date:DateTime"
S#aml Architecture project homepage: http://shaml.sztupy.hu/
GitHub project: http://github.com/sztupy/shaml/tree/master
I zipped an ASP.NET MVC Azure project up and copied it to another computer (both have VS 2008). I thought I could just unzip it in "Documents\Visual Studio\Projects", but I can't quite get it working. My site builds, but the browser doesn't see the master page or Site.css. Should moving projects around as Zip files just work?
My real question is, what's the best way for one developer to share an ASP.NET MVC Azure project among 3 different computers? Should I use something like Dropbox or Live Mesh? Or, github maybe?
OP here. The problem was that "Static Content" was not enabled in IIS on the second computer. The latest installation instructions for Azure (March '09 CTP) omit this crucial step. The first computer originally ran the Jan '09 CTP, whose instructions included the step about enabling Static Content. Moving projects around by zipping them up seems to work fine.
I love using git and github. I've shared my code among many computers with it. This was C# with Visual Studio solution files, so it sounds very similar to your situation.
Of course, I love git for source code management. I'd recommend it to anyone, but there's a decent learning curve if you're new to it. I can recommend resources that helped me, since it was really only about 8 months ago that I delved into it for the first time.
If you're not looking to adopt git as your source code management tool, then you might want to look at other options for moving code between machines.
Perhaps your IIS virtual folders are configured differently on the machines? You said it builds, but does not run. This suggests that configuration of the web site itself might differ between the 2 machines (and we're getting into some things I'm not aware of about how ASP MVC works at this point).
Yes, moving projects around in a zip should work assuming all of your files are in the subdirectory you zipped up. Sometimes you might add files to your solution that aren't in the subdirectory, and that can cause problems. References to other files need to be relative, instead of absolute.
A problem you might encounter is if both of you edit the same file, or accidentally overwrite an edited file with one from a developers machine that doesn't have that change yet.
Most developers use a source control system to share projects. Git is a fairly new one that has a growing audience. Subversion has been around a little longer and is very popular. Visual Studio integrates with TeamFoundation Server.
ProjectLocker.com offers free subversion hosting(so that you don't have to setup your own subversion repository).
Codeplex.com offers Team Foundation Server hosting for open source projects.
It sounds like the type of thing you see if the app-root isn't an application, or if the application isn't handling virtual directories correctly.
With virtuals; for example, you should rarely use "/foo/bar" - because if your app isn't installed at the site root you'll get unexpected behaviour - you mean "~/foo/bar", but this often needs extra code, as discussed here.