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.
Related
So I have an ASP.NET VB website that references several other projects (their DLLS are just put in the site's bin folder). I need to update a small piece of code in one of the projects, which I have done and it builds fine. However, when I copy over the new DLL to the website's bin folder it fails to build, and all the Imports statements say "BC40056: Namespace or type specified in the Imports xxx doesn't contain any public member or cannot be found", which results in a ton of errors like "is not defined" . There is no reference to the updated DLL in the website project's properties, but if I put the old version back it's all fine.
The project was copied from a server and the vbproj file contained references to other DLLs, but the HintPaths were a mixture of mapped drives and ..\..\..\. I've updated these so that they're all the full server location path, but this has made no difference. I tried adding the project to the same solution as the website and added a reference to the project instead, but this also made no difference.
I've done plenty of Googling but have yet to find a solution. Any help would be very welcome!
A few things
You don't want to just "place" the .dll's in the bin folder. One big reason is that when you do a "clean" project, the bin folder is deleted. So, anytime you do a clean project, what is in the bin folder is cleaned out. And a developer will often do a clean project if some kind of problem is occuring.
I would place those files in some folder in the project. (create a folder, or if its only one or two .dll's, then place them in the root of the project). At compile time, the .dll's will be copied to the bin folder. And if you using web deployment, then you can choose to have the .dll's all combined into one .dll. So, once again, you can see it makes little sense to place the .dll's in the bin folder, since during a build, they will not be required, and as noted, the resulting bin folder can and will as a "regular" development process be re-created (emptied out). I seen a good number of projects in which the developer did place the .dll in the bin folder (because they did not know where else to place the .dll's, and that was seemly the only place that the application worked. But, during a web build + deployment to the production server, those .dll's can be left behind - they not be copied to the final "deployment" build. (I'm basic saying don't do this!!).
You can also consider just creating folder called "packages" in the root. This is where all the nuget packages are placed. So, some folder for those .dll's is the idea here.
The other big issue? Well, just dropping some .dll's in some place does NOT give you the developer all the methods and properties of those .dll's when writing code (we are assuming these are managed code - not win x32 .dll's).
So, without adding a reference to that assembly, then I can't see how the project will even compile correctly, and how syntax checking, and general use of the assembly will ever work during the development process (so VERY perplexed that you don't have references to those .dll's - that as a general rule can't work).
Now, to use the assemblies? Yes, you want to add the .dll as a reference to the project.
So, in references, add the .dll as a reference.
And then in the property sheet for the refence? Make sure you have the "copy local" set = true.
eg this:
So, above is GhostScript.net reference. (a open source library to manipulate pdf's).
Note the long path name for the .dll location. But, MOST important is the copy local setting = true. This means during a compile and build (which as noted can clean out the bin folder), then the .dll will be output to the final build in the bin folder.
So, I can't see how you can compile anything without an actual reference to the .dll. That is quite much assumed and a given - else I see no way how your project can compile under any circumstances.
So, referance the .dll, and that should allow use of the class(s) and objects, and enable your code to compile. And make sure the copy local = true, as that is the process that will copy + place the .dll in the final output (bin) folder when you compile.
So it turns out that the project for the DLL I was trying to reference had the Target CPU set to x64. Changing this this to 'AnyCPU' then allowed me to reference it.
This post gave me the answer: Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)
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 using SVN to version a ASP.NET web project that I'm working on. I have recently decided to try versioning published versions of the site. I commit these to the repository along with tagged Release versions of the code in the root of the branch. This is proving useful as I can deploy to my server using SVN.
Problem that I'm facing is that I've had to version some files in my project's /bin folder (DLLs without external references), which has created a /bin/.svn folder. Problem is that VS.NET's Publish command insists on copying the .svn from the development branch /bin to the output folder's /bin. This basically 'switches' the binary files in there to point to the dev branch. The result is that the contents of the /bin folder never actually get committed to the compiled bin folder, because the working copy is pointing to a different part of the repository.
Is there any way to force visual studio to ignore the .svn folder on publish? Alternately, is there another way to handle the inclusion of static .dlls in a project without putting them in the bin folder, so that the /bin can be excluded from SVN (as it should be) (not using the GAC)?
Definitely do not put the bin folder in the repository. This will give you nightmares forever.
Just put your static referenced .dll's in a folder called "Libraries" or whatever, and set your project references to them. They'll be copied to the output automatically.
I suggest that you don't version anything in the .bin folder. Instead put all of your referenced assemblies in a folder outside of your project folders. Then deploy it and build it where ever it is going. The build process will pull all of the dlls in as needed. This would then remedy your .svn folder in the bin folder issue!
Hmm.. Put them into a separate folder in the solution and reference them. Now why didn't I think of that (doh!). Think I've been staring at the screen too long.
Thanks all.
I have a web application project. I have DLLs that I reference in the project stored in my bin/ folder. Well, whenever I do a rebuild or clean from Visual Studio, it will delete everything in that folder. How do I prevent this from happening?
Do not put anything into bin yourself. bin is the target folder for binaries - it is not a source folder for binaries.
Create yourself a lib folder or something like that to put your third-party binaries into. You might even name it "Third Party Binaries", since not everyone knows that "lib" means the same thing. Make your references to the binaries in this folder, and Visual Studio will copy them into bin when necessary (including on a rebuild).
I'll stay away from asking the 'why' question and just state the how. Mark the files as read only and VS shouldn't delete them.
Follow John Saunders answer and put your .dll's into a separate folder. In my case I named this folder "ServerAssemblies". Then modify your project file (.csproj in my case) and add an "AfterRebuild" target.
<Target Name="AfterRebuild">
<ItemGroup>
<ExtraAssemblies Include="$(SolutionDir)ServerAssemblies\**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(ExtraAssemblies)" DestinationFolder="$(ProjectDir)bin\"></Copy>
</Target>
Can you explain why you have to store it in the bin folder to begin with? i always create a separate folder for example /components where i store all referenced dll's.
One thing the "don't do it that way!" people are forgetting is source control and 3rd party software. Using SVN you often get files that if physical references were used would create mismatches when they're not in the same physical location.
One CMS I'm working with at the moment prebuilds the VS project and solution when you set up another "instance" of it. It dumps in some dlls it needs... but if you rebuild they vanish.
The simple solution in both cases is to do as stated above and call it done.
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.