I've just started using Subversion with ASP.NET web applications via the VisualSVN IDE plugin. There are a bunch of files which Visual Studio automatically generates so I don't want to version control these since they're not really part of the codebase and not required to build.
Does anyone have a definitive list of the main files that should be ignored when commiting to Subversion from an ASP.NET Web Application? and how would I go about ignoring these files. If possible I'd like to set it globally so that I don't have to keep doing the same thing for every ASP.NET Web Application that I write and create a new repository for.
Answers
A list of files to ignore as submitted in the answers below,
bin
obj
*.exe
*.pdb
*.suo
_ReSharper.*
*.user
General concensus seems to be that these should be ignored on a per project basis at the creation of the repository. They will then be ignored by all users using the repository.
Not really 'definitive', but I always ignore .suo and .user files and the bin/ and obj/ directories
Here's my ignore list from TortoiseSVN. VisualSVN requires TortoiseSVN and uses its settings.
bin obj *.exe *.pdb *.suo _ReSharper.* *.user
I haven't committed any unwanted (or not committed any wanted) files with this setting.
If you have any WCF service references then you only need to include the files Reference.cs and Reference.svcmap for each service reference.
The AnkhSVN plugin for Visual Studio has a list of files to ignore automatically and will only commits the files needed.
At least that's how I find it. It's taken me a few attempts at setting up the repository correctly but with AnkhSVN only commits a subset of he files that TortoiseSVn wants to commit. If ignores files recompiled on every Build for example.
Depending on your situation, you might want to keep the Web.config out of revision control as well. Different developers might require different configuration files for a website.
I'd recommend setting up a separate directory in your repository with a reference configuration file for the website and ignoring *.config on the actual project directory.
Additionally, to cover case sensitivity issues with "bin", I had to add [Bb]in to mine. So I have:
[Bb]in obj *.exe *.pdb *.suo _ReSharper.* *.user
Also, this link explains how to handle project specific excludes as well so that others get the same exclusion behavior only for the same project when they check it out:
http://svnbook.red-bean.com/en/1.1/ch07s02.html
I used the svn:ignore property on a particular directory to exclude a certain set of files that were copied into there (but I still wanted the directory itself in svn).
Use VisualSVN to do the initial "Add files to repository" and it automagically ignores the stuff you don't want-such as suo files and the bin/obj folders.
Related
I am attempting to setup Team City for CI on my project. We currently have 9 developers working on the project and using Mercurial for source control. Right now all web.config files are ignored in the main project repo and the web.config files are located in a separate repo so that we do not have to use a dozen transforms.
How can I configure Team City/MS Build so I can checkout both repos (have this working so far) and then update the repos and copy the web.config to the main project folder before doing the build?
What you actually want to do is:
Each developer has his own web.config, but you want the build to use the same "central" web.config each time and ignore the developers' own web.config versions.
Correct?
If yes, I would do it a different way:
You can let the developers use their own web.config files by default, but still put the "central" web.config into the main project repository with a different file name (for example, web.config.build.
Then you can use BeforeBuild (in the .csproj file) in a way so that it will be automatically copied to web.config when there is no web.config file present (which should be the case on the build server, but not on the developer machines).
Read this answer to see how I'm doing something similar:
how to ignore files in kiln/mercurial using tortoise hg “that are part of the repository”
You can create a second VCS root and have it 'merge' files in your checkout on the teamcity machine
create a second VCS root in teamcity
append ignore rules to match only your *.config file as needed and place it in the correct folder
example ignore pattern from the top of my head:
-:*
+:web.build.config=>website/
But i would suggest you follow the approach of Christian Specht because when you have a web.example.config which you copy to web.config on pre-build event you are able to modify it with new settings. This will get picked up easily by teamcity because you can have it 'clean' the directory (with Swabra) to remove the 'old' web.config file and get it re-copied from the (new) web.example.config
I have a Sitecore/ASP.NET projects that I'm developing. Today at some point I inadvertently hit the "Clean" option in the solution context menu. It took me a while to figure out why my site was hopelessly broken. Turns out Visual Studio went ahead and deleted several required assemblies from the \bin dir which are not part of my project.
How can I prevent this from happening again?
The odd thing is that it did NOT delete everything... just a small handful. It left many that are not directly referenced by my project. This makes me wonder exactly what this feature is supposed to do? Is there some sort of file flag I can set? None of the files are set to read-only. If you're interested in details, the following got deleted:
Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web.dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll
UPDATE: You know what... I guess what I'm really more interested in here is WHY Visual Studio is leaving most of the files and only deleting these specific ones.
The correct answer to your problem will depend on how you are referencing the assemblies and how you include them in your project output.
The bin and obj folders generated by a project are best considered "output" folders; these folders should only contain files produced by the project build.
When you perform a clean or rebuild of a project, all intermediary and compiled files are deleted from these folders.
You should be comfortable this is happening.
You should be able to restore these folders by running the build process at any time. If you have added files to these folders directly, it breaks the purpose of these folders and means you ought to rethink how you're adding those files.
The preferred way to reference compiled assemblies is to add them somewhere inside your source folders. From there, they can be added to a source control system as easily as any other file and can be referenced/copied by projects which depend on them. In my work, we have a "Libraries" folder which contains numerous third-party assemblies referenced by multiple projects in our solution hierarchy.
Try using a source tree like this and seeing if it works for you:
/Projects/My Solution/
/Projects/My Solution/Libraries/
/Projects/My Solution/Project A/
/Projects/My Solution/Project B/
We always add an AfterBuild event to the project file containing Sitecore.
<Target Name="AfterBuild">
<CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*">
<Output TaskParameter="Include" ItemName="FilesToArchive" />
</CreateItem>
<Copy SourceFiles="#(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" />
</Target>
Where the CreateItem Include is the path to where you have placed your Sitecore binaries.
Put the dlls in a different directory. You will probably not want them as part of the project. Reference the dlls from the new directory. When you compile the dlls will be copied to the bin directory.
I work with lots of projects and keep a bin directory at the root of my projects to store 3rd party dlls for exactly this reason.
Example directory structure:
MyProjects
- bin
- 3rdParty.dll
- Project1
- Project2
- ProjectN
This allows all the projects to have a well-known reference location for 3rd party dlls without having to copy the dll into each project.
If you are working on a team you should all agree on a standard directory structure for your code. This will save you lots of headaches beyond just this.
In case of Sitecore, just make sure to set the property of the reference(Sitecore.Kernel, Sitecore.Client, etc):
'Copy Local' = false.
I believe that if you put these files in a subdirectory other than bin, Visual Studio won't remove them. You can still make the new subdirectory part of your deployment.
Well, I'm going to go ahead and answer my own question, since it seems like the simplest answer so far. I marked the assemblies in question as Read-only. Now they don't get cleaned.
Still wondering why most of the others don't get deleted.
We're in the middle of changing from VSS to Subversion and we have a website project on our Subversion Repo. We've removed the Bin folder as it causes all kinds of chaotic tree conflicts since our development solution contains some Class Library projects the Website project depends on (set up as project references in our solution). We also have a couple of 3rd party library DLLs in the Website's Bin folder too.
The next phase of our project involves a designer modifying themes to our website. I'd like for him to be able to just open the Website project in VS 2005, modify the CSS files he needs to on his working copy, and test his files on his localhost. He'll need the most up-to-date DLL files for him to be able to do this.
Is there anyway to add the Bin folder DLLs to subversion, and configure TortoiseSVN or subversion so that we can commit our newest DLLs (project dependencies in developer's solution files) but ignore them on update (per client I guess)? It would also be handy to have our 3rd party website dependencies on Subversion too.
You should not put 3rd-party assemblies into the bin folder. In fact, you should assume that the bin folder will be emptied before each build. It is a place to put the output from a build, not a place to put inputs.
Put these binaries in to some other folder, maybe "3rdPartyAssemblies". Use a file reference to these files, and they'll be copied into the bin folder, as outputs.
Would it not be possible to structure it like this:
Trunk/
WebApp/
ClassLibrary1/
ClassLibrary2/
ClassLibrary3/
3rdPartyDlls/
build.bat
The web app is what pulls all the class libraries and the 3rd party dlls in to the WebApp's Bin folder (All of these will be referenced via relative links). You can then setup TortoiseSvn to call the build.bat file on update through client side hooks. You would also setup IIS on the designer's machine to point to the WebApp directory.
As other users have pointed out, you could use svn externals to pull in those enterprise wide class libraries.
What most everybody else has said regarding '3rdParty' is correct.
You may also consider svn:externals to pull in related directories including a '3rdParty' assemblies directory, or even output directories from builds that can be triggered by a check in to assure currency.
The approach we've taken is, rather than having the Libraries in the same solution, they have separate solutions and we (well, our Build server) compiles them and checks the compiled DLLs into sourcecontrol under "Dependencies" which is always mapped to C:\Dependencies on all developers machines. We then use file references to this folder from the website project.
Thi way you can give your designer the Website project along with a copy of C:\Dependencies and they'll be none-the-wiser =)
We don't sourcecontrol the bin-folder since it would be updated everytime you run a compile. Instead, we keep references to 3rd part libs in a separete folder that is under version control, that we have references to in our project.
With this setup and using "copy local = true", they are automatically added into bin upon compilation.
Secondly, we will only commit new binary files when we update the 3rd-part binaries.
This approach is also possible to do for your internal dlls, so that your designer can just compile his visual-studio-solution so taht any relevant dlls would be put into his bin-folder and hence, create a functional site locally on his machine.
background:Me and my coworkers are working on asp.net mvc project ... we have a computer that works as a server which is where the project will be stored on... each of us has a copy of the project and we got tortoise cvs set up.
questions:
when you want to commit something, what files exactly do you commit?.. asp.net reports many dll files, csproj files, cs and sln files that appear to be different from the server's.
Maybe my question is not the right one I should ask so I would appreciate some insight on whats the best approach for working in groups.
The basic csproj file should be committed whenever you add or remove things from the project, to ensure that the project has all the correct files. The solution (sln) is a good one to commit, for the same reason, although I've also seen it done without. You'd also want to commit any cs files, naturally, as they're the main focus of things.
DLL files should only be committed if they're outside references--internal dlls to your project can be ignored, as they'll be built by each computer in turn. You also want to avoid .user files as unnecessary. Ignore the 'bin' and 'obj' folders for each directory, when it comes to commits as well.
You really shouldn't check in anything that the project can generate itself. So no need to check in your bin or obj folders or anything like that, you also want to ignore any user preferences files.
This includes dlls, unless they are third party dlls, then you want to check them in to ensure everyone is working against the same version and this way you don't have to keep changing reference paths.
I don't work in asp.net, so I will respond generically.
We have a subversion code repository for our version system, cvs works well too. Developers retrieve all updated code from the repository, do work, make sure it's working correctly, do another get, re-compile, test, and then commit source code changes to the repository. On a regular basis you can have a tool or manually build the application from the repository, and deploy to a testing server. No compiled code should be placed in the repository.
-Jay
We use the following project structure in SVN (but this applies to CVS as well).
+ tags
+ branches
> trunk
+ build (build scripts)
+ lib (external libraries)
> src (source code)
>> Organization.App (solution name)
>> Organization.App.Core (code library)
+ Config
> Domain
> Model
> Persistence
> Queries
> Services
> Persistence
> Services
>> Organization.App.Web (mvc web app)
> Assets
+ Images
+ Scripts
+ Stylesheets
+ Controllers
+ Views
+ ViewModels
We put all our 3rd party dependencies into the lib folder. Including MVC, which can be bin deployed. See this article by Phil Haack. So when a new developer comes online all they have to do it check out the trunk, and they should have everything they need to get going. Using a CI server is a cinch because all of the projects dependencies are encapsulated by the lib folder and all of the visual studio projects make reference to those dll's in that lib folder.
Does that make sense?
Never mind the core folder and the web folder. That's just how we structure our projects within the solution. But that's a whole other conversation. :)
We keep everything except the BIN/OBJ folders in SVN. We have all third party Libraries in a seperate folder that they are referenced from.
Kindness,
Dan
If you are using a database change management tool, such as Tarantino, then you will also want to check in SQL change scripts and/or populate scripts. We have a folder in our 'Core' solution where we keep these, ie 'Core/Database/Updates'. We use SQL Compare to find changes in our database then we check in those SQL change scripts so that other developers can just run them locally. We have a nant task setup to call on Tarantino to sync up the other build environments (Dev, QA) and run any new change scripts.
I'm currently working on an ASP.NET project with multiple developers using Subversion for code distribution, but it's quite frankly totally messed up at the moment. The person who set up the Subversion repository have included config files specific to their computer, bin\* directories, and other such things.
I, being the guy who has to check out this repository and get it to run on my computer, am pretty frustrated by this since it's taken me a while to sort it all out to get it to compile at all. Now I'm thinking about writing a document for Subversion guidelines to send to the technical leader at my company so that we can get the process standardized and avoid these kinds of problems.
What I'm looking for is input on the guidelines. Here's the start for them, and hopefully we can make something good out of it:
The file structure should be set up to have third-party libraries checked in outside the build output directories (since they won't be included in the repository.) The name of this directory should be "Libraries".
No machine-specific files should be included in Subversion. Therefore, only a template of Web.config is checked in, which is customized by the developers to suit their machine. This behavior is included in Visual Studio 2010 by default and the individual configuration files (Web.Local.config) automatically have the template (Web.config) applied. The local configuration file still shouldn't be included in Subversion though, so long as it applies for a specific machine.
Solution and project files must not contain any absolute paths.
An ignore list should be set up. Start with:
'
*.user
obj
'
Example file structure for an ASP.NET 2.0 web site with a class library specific to the web site and a third-party library:
'
/trunk/
Libraries/
ThirdParty.dll
MyClassLibrary/
bin/ [Ignore]
obj/ [Ignore]
Properties/
AssemblyInfo.cs
SomeClass.cs
MyClassLibrary.csproj
- Holds references to third-party libraries. For example:
../Libraries/ThirdParty.dll
MyWebApplication/
bin/
ThirdParty.dll [Ignore; copied by build process]
ThirdParty.dll.refresh
- Contains "../Libraries/ThirdParty.dll"
Default.aspx
Default.aspx.cs
Web.config [Ignore]
Web.config.template
MySolution.sln
- Holds list of projects.
- Has reference information for projects.
'
An alternative to using Web.config.template would be to include a Local.config file from Web.config, but this might be less flexible.
When using a Web Application project rather than a Web Site project, the references will be stored in the project file instead of in .refresh files, so the bin/ folder will be ignored.
Can someone see errors in the above suggestions? Is something missing? Does anyone have suggestions for the ignore list? I just started with a couple of entries for now.
I think that you are a good step on the way. But why not put an ignore on the entire bin folder in /MyWebApplication, instead of the files? You wouldn't add your build output to subversion would you? I would definately consider that a bad practice.
Also, if possible, you could add the web.config file to subversion, but in the element reference a new file with appSettings: for example
<appSettings file="local.config">
Then have the local.config file be ignored by svn. That is how I always operate.
But of course that only works if every configurable parameter is in the appSettings (one of the reasons why I dislike the provider model, because all the providers need to get connection strings from a connectionString element, and you cannot reconfigure them to take a connection string from appSettings)
Edit: troethom enlightened me and pointed out, that you can also override the connectionString configuration settings in a separate file
<connectionStrings configSource="ConnectionStrings.config"/>.
So the thing that I would do is place the actual web.config file under subversion control, but let those other files that override the settings locally be ignored by svn.
You should add the .refresh files; not the real DLLs.
The Visual Studio project system sends a list of files that should be added to source control to SCC Providers. AnkhSVN is a Subversion SCC provider that uses this information to suggest adding these files (and not the other files).
VisualSVN and other Subversion clients that only look at file extensions don't get this information from ASP.Net.
(Note: if you remove the .refresh file, Visual Studio will add the DLL to the list of files that should be committed)