So, I have an asp.net mvc app that is being worked on by multiple developers in differing capacities. This is our first time working on a mvc app and my first time working with .NET. Our app does not have a lot of unit tests in it...
The problem we are having is trying to keep each other from overwriting each others changes. For example:
Two developers are both working on the app and Jon (not his real name) makes a change to a controller, compiles a new dll, and checks in his stuff (both the controller and the dll.) Our svn system automatically updates our DEV server with the changes that Jon just made.
Clyde (also not a real name) also makes a change right about the same time but did not update the code with Jon's change and commits a new dll thereby "forgetting" about Jon's change.
This happens a lot. The question I'm asking is more of a workflow question - how do we solve this issue? Is it just a matter of Clyde needing to be more careful? Can anybody recommend a decent process for us to use?
You don't check in the DLL's. Exclude the bin folder from Subversion in its entirety. It's the .cs files that matter and that will be compiled locally on every computer that checks out the code from Subversion. If your deployment script don't compile the code but is just a simple xcopy statement, you need to either introduce csc to the script or implement a continuous integration system like TeamCity.
The issue you describe is already handled by subversion. When Clyde tries to commit his changes subversion will detect the conflict and offer him the possibility to merge his changes.
This is exactly the scenario that Subversion and other version control systems are designed to avoid. When Clyde checks in, he should get an "out-of-date" error and his commit should fail, thereby forcing him to update his working copy and get Jon's changes before he can commit his own.
Check out the SVN video tutorials from dime casts. These show you best practices like how to setup your project, and how to do the "check in dance" which will avoid the situation you ran into/
http://www.dimecasts.net/Casts/ByTag/SVN
I've used Subersion and .NET application together. Basically what we learned was that you should always do an update to your working copy before making a checkin. That way, any changes made by other developers will be brought down to your working copy and any merge conflicts will be quickly known to you. You can then fix the merge conflicts, checkin and continue to work. If your second developer then updates their working code, the first developers merged code will be brought down and the process will be repeated.
Hope this helps.
ignore the folders bin and obj, but we have bin and Bin.
use svn:ignore
[bB]in
[oO]bj
*.suo
Related
In my line of work I'm often retrieving very specific versions of crusty ASP.NET web apps from their long-forgotten repositories, making minor changes and then recompiling.
A major annoyance in this process is having to create a virtual directory for every web project that I need to recompile. I don't have any problems with the process, but it's tedious and still a very manual process on .NET 1 projects.
Is there a fairly simple way to recompile the binaries of the csproj without setting up a new virtual directory?
Edit: I don't mind using command line tools, or external solutions, as long as they're fairly simple and straightforward.
I'm not sure there's any other way unless you can convert the project to vs 2005.
I ran into a similar issue when i was dealing with a web project that i needed to manage a few branches that all wanted the same virtual directory. I wrote this small app that does some switching of the virtual for you automagically.
I have added on to the app to make it more functional (supporting more than just one project at once)... and i'm sorry to say i have never update the code on the blog. This might just serve as a good starting place for you to manage your virtual directories.
I will try to get the latest code up on the blog soon and i will update this post when i do.
but in the meantime check out the source here
ps. i know this version of the code needs to be cleaned up this version was just a proof of concept.
I'm using Perforce, if that changes the tune of the answers at all.
I'd like to implement a build process that, when a solution is built in a "release" mode, tags the entire source tree with a label and pushes the output of the build (DLLs, webpages) to a /build/release directory in source control. This directory should always contain the latest complete build, nothing less and nothing more, so I can yank that directory to production servers in its entirety and it's ready to go.
Now say I had a DLL in a previous release that the new build is not supposed to include. Does this mean the best practice for updating that /build/release folder is to check the entire thing out, delete everything in it, add the new build files, and sync it? Sounds like an obvious answer, but I want to make sure I'm not missing some other voodoo that might be a better way to do it.
I think you are missing the simple voodoo:) You should consider just using a plain old file system for your build drops. Source control is designed to manage change, versioning, and collaboration and there really is no need for any of this related to builds. The whole point to an build system is to be able to reproduce the source code and create the application at a moments notice so I would focus on being able to do that more than relying on the permanent storage of the output files. Be sure to back up the build drop folder structure just as you would the source control database. Use a folder naming scheme that includes the build number in the filename. I would store all of the builds (back at least several) because there are times when QA wants to restore an old build to test in order to compare features or resurrect a bug. Using this system every build gets a new folder so you don';t have to worry about deleting out old files.
I'd say "Yes" - you should to start with a blank folder structure for your builds (regardless of source control system).
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
In my automated NAnt build we have a step that generates a lot of code off of the database (using SubSonic) and the code is separated into folders that match the schema name in the database. For example:
/generated-code
/dbo
SomeTable.cs
OtherTable.cs
/abc
Customer.cs
Order.cs
The schema names are there to isolate the generated classes that an app will need. For example, there is an ABC app, that will pull in the generated code from this central folder. I'm doing that on a pre-build event, like this:
del /F /Q $(ProjectDir)Entities\generated*.cs
copy $(ProjectDir)....\generated-code\abc*.cs $(ProjectDir)Entities\generated*.cs
So on every build, the Nant script runs the generator which puts all the code into a central holding place, then it kicks off the solution build... which includes pre-build events for each of the projects that need their generated classes.
So here's the friction I'm seeing:
1) Each new app needs to setup this pre-build event. It kind of sucks to have to do this.
2) In our build server we don't generate code, so I actually have an IF $(ConfigurationName) == "Debug" before each of those commands, so it doens't happen for release builds
3) Sometimes the commands fail, which fails our local build. It will fail if:
- there is no generated code yet (just setting up a new project, no database yet)
- there is no existing code in the directory (first build)
usually these are minor fixes and we've just hacked our way to getting a new project or a new machine up and running with the build, but it's preventing me from my 1-click-build Nirvana.
So I'd like to hear suggestions on how to improve this where it's a bit more durable. Maybe move the copying of the code into the application folders into the NAnt script? This seems kind of backwards to me, but I'm willing to listen to arguments for it.
OK, fire away :)
How often does your DB schema change? Wouldn't it be possible to generate the database-related files on demand (e.g. when the schema changes) and then check them into your code repository?
If your database schema doesn't change, you can also package the compiled *.cs classes and distribute the archive to other projects.
We have two projects in our solution that are built completely out of generated code. Basically, we run the code generator .exe as a post-build step for another project and along with generating the code, it automates the active instance of visual studio to make sure that the generated project is in the solution, that it has all of the generated code files, and that they are checked out/added to TFS as necessary.
It very rarely flakes out during the VS automation stage, and we have to run it "by hand" but that's usually only if you have several instances of VS open with >1 instance of the solution open and it can't figure out which one it's supposed to automate.
Our solution and process are such that the generation should always be done and correct before our auto-build gets to it, so this approach might not work for you.
Yeah I'd like to take VS out of the equation so that a build from VS is just simply compiling the code and references.
I can manage the NAnt script... I'm just wondering if people have advice around having 1 NAnt script, or possibly one for each project which can push the code into the projects rather than being pulled.
This does mean that you have to opt-in to generate code.
As part of improvements to our build process, we are currently debating whether we should have separate project/solution files on our CI production environment from our local development environments.
The reason this has come about is because of reference problems we experienced in our previous project. On a frequent basis people would mistakenly add a reference to an assembly in the wrong location, which would mean it would work okay on their local environment, but might break on someone else's or on the build machine.
Also, the reference paths are in the csproj.user files which means these must be committed to source control, so everyone has to share these same settings.
So we are thinking about having separate projects and solutions on our CI server, so that when we do a build it uses these projects rather than local development ones.
It has obvious drawbacks such as an overhead to maintaining these separate files and the associated process that would need to be defined and followed, but it has benefits in that we would be in more control over EXACTLY what happens in the production environment.
What I haven't been able to find is anything on this subject - can't believe we are the only people to think about this - so all thoughts are welcome.
I know it's anachronistic. But the single best way I've found to handle the references issue is to have a folder mapped to a drive letter such as R: and then all projects build into or copy output into that folder also. Then all references are R:\SomeFile.dll etc. This gets you around the problem that sometimes references are added by absolute path and sometimes they are added relatively. (there's something to do with "HintPath" which I can't really remember)
The nice thing then, is that you can still use the same solution files on your build server. Which to be honest is an absolute must as you lose the certainty that what is being built on the dev machine is the same as on the build server otherwise.
In our largest project (a system comprising of many applications) we have the following structure
/3rdPartyAssemblies /App1 /App2 /App3 /.....
All external assemblies are added to 3rdPartyAssemblies/Vendor/Version/...
We have a CoreBuild.sln file which acts as an MSBuild script for all of the assemblies that are shared to ensure building in dependancy order (ie, make sure App1.Interfaces is built before App2 as App2 has a reference to App1.Interfaces).
All inter-application references target the /bin folder (we don't use bin/debug and bin/release, just bin, this way the references remain the same and we just change the release configuration depending on the build target).
Cruise Control builds the core solution for any dependencies before building any other app, and because the 3rdPartAssemblies folder is present on the server we ensure developer machines and build server have the same development layout.
Usually, you would be creating Build projects/scripts in some form or another for your Production, and so putting together another Solution file doesn't come in the picture.
It would be easier to train everyone to use project references, and create a directory under the project file structure for external assembly references. This way everyone follows the same environment.
We have changed our project structure (making use of SVN Externals) where each project is now completely self-contained. That is, any references never go outwith the project directory (for example, if Project A references ASM X, then ASM X exists within a subfolder of ProjectA)
I suspect that this should go some way towards helping solve some of our problems, but I can still see some advantages of having more control over the build projects.
#David - believe it or not this is what we actually have just now, and yet it's still causing us problems!
We're making some changes though, which are forced upon us due to moving to TeamCity and multiple build agents - so we can't have references to directories outwith the current project, as I've mentioned in my previous answer.
Look at the Externals section of this link to see what I mean - http://www.dummzeuch.de/delphi/subversion/english.html
I would strongly recommend against this.
Reference paths aren't only stored in the .user file. A hint path is stored in the project file itself. You should never have to check a .user file into source control.
Let there be one set of (okay, possibly versioned) solution/project files which all developers use, and the Release configurations of which are what you're ultimately building in production. Having separate project files is going to cause confusion down the road, when some project setting is tweaked, not carried across, and slipped into production.
You might also check this out:
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx
http://bytes.com/forum/thread268546.html