Files in a VB.NET project to put under Version control
-
I am learning to program in VB.NET(2008 Express) and also learning to use version control software (TortiseSVN). I am creating simple projects with VS while I learn the language(Using the book VB 2008 Step by Step ). I have not been able to determine if I should put all the files in the project directroy under version control and if not what files and folders to exclude. I am not sure what the files in the project directory do, any infomation would really be helpful. eg of contents of project folder. bin (folder) My Project (folder) obj (folder) *.vb *.resx *.vb *.sln *.suo *vbproj *.vbproj.user Thanks cages
-
No need to filter out, you can put everything on the share directory! j/k :p VisualSvn is great for that, it's a shame you can't use it. In C#, you should ignore these (maybe VB.NET has more?) - Solution.suo which contains "solution user options" - Project/bin/ which contains your builds - Project/obj/ which contains temporary files for your builds Also, the typical SVN structure is to have your application files within the "trunk" sub directory. This is useful so you can have another root directory for documentation, installer files, etc. and so you can have branches and tags directories too. On the other hand, I've just switched to "distributed version control", namely Mercurial with TortoiseHg and I strongly recommend everyione that they look into it. I won't try to sell it to you (it's free :doh: ), but if you're changing for a version control system, it probably is the best time for you to evaluate it. Even if you don't go for it, it will help you understand the version control concept in general. And there are many advantages to Mercurial like local commits/branches and a "real" tag feature. Here's an article I read recently (thanks to the CodeProject daily newsletter) about structuring a Git repository (it's the same as Mercurial, but it was designed by some operating system inventor or whatever ;) ) : http://nvie.com/posts/a-successful-git-branching-model/?[^]
- Project/bin/ which contains your builds
What is the general / advised approach when developing reusable components for later inclusion via SVN externals? Currently we have, e.g. Component x - reusable component Application 1 - application that uses component x Application 2 - application that uses component x In order to get applications 1 & 2 to use component x, we include the bin\* directories in SVN and refer to them in the applications as SVN externals pointing at the bin directories. I'm guessing from the "don't include bin" suggestion that there's a better way of doing this - any suggestions? Bearing in mind that we don't want the applications to recompile the component each time.
-
I am learning to program in VB.NET(2008 Express) and also learning to use version control software (TortiseSVN). I am creating simple projects with VS while I learn the language(Using the book VB 2008 Step by Step ). I have not been able to determine if I should put all the files in the project directroy under version control and if not what files and folders to exclude. I am not sure what the files in the project directory do, any infomation would really be helpful. eg of contents of project folder. bin (folder) My Project (folder) obj (folder) *.vb *.resx *.vb *.sln *.suo *vbproj *.vbproj.user Thanks cages
I agree with the other responses - ignore obj and bin folders and .suo and.user files. I recommend Mercurial, also called Hg, as a good source control solution. It's dead simple. You can install TortoiseHg for GUI and the Explorer integration, and VisualHg for Visual Studio integration (including VS Express?). It can sync to your own hard drive, network drive, private web or ftp, or to a free account on BitBucket. Some say it is easier than Subversion and Git, both of which I've looked into but never used. We currently use Source Safe and I'm evaluating Mercurial and love it so far. But no doubt I would love a good tar and feathering than to continue to work with and trust Source Safe. Do not use Source Safe. Almost anything is better. I read recently that Source Safe is the most dangerous software ever written that was not intentionally designed as a virus. Let's all have a moment of silence for Gregory.Gadow having to use it.
Mike
-
-
I am learning to program in VB.NET(2008 Express) and also learning to use version control software (TortiseSVN). I am creating simple projects with VS while I learn the language(Using the book VB 2008 Step by Step ). I have not been able to determine if I should put all the files in the project directroy under version control and if not what files and folders to exclude. I am not sure what the files in the project directory do, any infomation would really be helpful. eg of contents of project folder. bin (folder) My Project (folder) obj (folder) *.vb *.resx *.vb *.sln *.suo *vbproj *.vbproj.user Thanks cages
We use TSVN and VisualSVN. Here is my global ignore pattern, this will prevent listing folders or files when you add them to the repo:
*/bin */obj *.bak *.*scc *.user *.suo *.webinfo bin obj *.pdb *.exe *.DCS *.zip
2 years ago we moved from SoureSafe to SVN that is why I added to ingnore the .scc file.
-
- Project/bin/ which contains your builds
What is the general / advised approach when developing reusable components for later inclusion via SVN externals? Currently we have, e.g. Component x - reusable component Application 1 - application that uses component x Application 2 - application that uses component x In order to get applications 1 & 2 to use component x, we include the bin\* directories in SVN and refer to them in the applications as SVN externals pointing at the bin directories. I'm guessing from the "don't include bin" suggestion that there's a better way of doing this - any suggestions? Bearing in mind that we don't want the applications to recompile the component each time.
We have a folder called 'Assemblies', into which we copy the generated .dlls when they are ready for consumption. This allows us to make changes (and check them in, so we don't lose our work) without affecting the 'upstream' items. When it is ready for a new 'release', copy the completed bin files into the Assemblies folder. Then, the upstream projects have a References folder, with an entry for each 'subsystem' that needs to be referenced which points to the Assemblies folder for the subsystem. Bin is not stored in our source control. (we are using TortoiseSVN)
-
This, Ankh svn plugin for Visual Studio will handle everything for you, you just check out, commit, etc a solution and the plugin will handle everything for you.
He's using VS Express, plug-ins are not supported.
-
I am learning to program in VB.NET(2008 Express) and also learning to use version control software (TortiseSVN). I am creating simple projects with VS while I learn the language(Using the book VB 2008 Step by Step ). I have not been able to determine if I should put all the files in the project directroy under version control and if not what files and folders to exclude. I am not sure what the files in the project directory do, any infomation would really be helpful. eg of contents of project folder. bin (folder) My Project (folder) obj (folder) *.vb *.resx *.vb *.sln *.suo *vbproj *.vbproj.user Thanks cages
As with so many things: it depends. If you are just doing hobby projects (which it sounds like you are) then excluding the output from compiles (the obj and bin folders) is absolutely fine. However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control. The reasoning being that the state of the build machine can have an impact on the final deliverable ... add a patch and the compiler might produce something subtly different. It is also common under configuration management best practices to place documentation (program specs, user guides, operations manuals, etc) under version control too. As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
-
I am learning to program in VB.NET(2008 Express) and also learning to use version control software (TortiseSVN). I am creating simple projects with VS while I learn the language(Using the book VB 2008 Step by Step ). I have not been able to determine if I should put all the files in the project directroy under version control and if not what files and folders to exclude. I am not sure what the files in the project directory do, any infomation would really be helpful. eg of contents of project folder. bin (folder) My Project (folder) obj (folder) *.vb *.resx *.vb *.sln *.suo *vbproj *.vbproj.user Thanks cages
The only bin file to put in would be the .exe or any file it requires to run (.dll?). Think of doing a build / clean before checkin, then add in the few files needed to run your app. (My gang keeps checking in .suo files, they come out read only and screws my ability to build...) Note .sln and .vbproj are required, they're your solution and project files. .vb is your source code. I think .resx is generated by Visual Studio...
-
As with so many things: it depends. If you are just doing hobby projects (which it sounds like you are) then excluding the output from compiles (the obj and bin folders) is absolutely fine. However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control. The reasoning being that the state of the build machine can have an impact on the final deliverable ... add a patch and the compiler might produce something subtly different. It is also common under configuration management best practices to place documentation (program specs, user guides, operations manuals, etc) under version control too. As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
Peter Trevor wrote:
However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control.
However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract. Consequently one would not check in source/proj/etc files at the same time as deliverables.
Peter Trevor wrote:
As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
Better to figure out what files are actually required. It becomes obvious with a clean extract.
-
Peter Trevor wrote:
However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control.
However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract. Consequently one would not check in source/proj/etc files at the same time as deliverables.
Peter Trevor wrote:
As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
Better to figure out what files are actually required. It becomes obvious with a clean extract.
jschell wrote:
However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract.Consequently one would not check in source/proj/etc files at the same time as deliverables.
Quite correct, sorry if that wasn’t clear. Overall in SCM (software configuration management) *final* deliverables are under version control but that does not mean that those deliverables are tracked in interim stages. (Depending on the specifics of the SCM plan being used ‘candidate’ final builds may also be version controlled.) As you point out, candidate final deliverables are usually built from a clean extract (and usually on a clean build machine) after the developer has checked in his changes. I wasn’t trying to explain SCM in detail, merely make the OP aware of its existence.
jschell wrote:
Better to figure out what files are actually required. It becomes obvious with a clean extract.
But if you aren’t following an SCM process it is better to err on the side of caution. Especially if (as is the case with the OP) you aren’t sure what you need to track to begin with ... you can always fine tune by dropping items over time as you gain a better understanding. It’s harder to fine tune the other way.
-
The only bin file to put in would be the .exe or any file it requires to run (.dll?). Think of doing a build / clean before checkin, then add in the few files needed to run your app. (My gang keeps checking in .suo files, they come out read only and screws my ability to build...) Note .sln and .vbproj are required, they're your solution and project files. .vb is your source code. I think .resx is generated by Visual Studio...
CDMTJX wrote:
I think .resx is generated by Visual Studio...
.resx files are resource files. They can potentially contain images, icons, strings, and other data necessary for your program. If .vb is source code then .resx is source ‘non-code’.
-
CDMTJX wrote:
I think .resx is generated by Visual Studio...
.resx files are resource files. They can potentially contain images, icons, strings, and other data necessary for your program. If .vb is source code then .resx is source ‘non-code’.
Yup, I wasn't clear... VB creates .resx during project editing, not during building. So it is required to build with, not the result of a build, and not edited by programmers (though I've been known to edit such files with C++ and C#...). Check .resx into source control.
-
RapidSVN is a good simple rich client
-
We have a folder called 'Assemblies', into which we copy the generated .dlls when they are ready for consumption. This allows us to make changes (and check them in, so we don't lose our work) without affecting the 'upstream' items. When it is ready for a new 'release', copy the completed bin files into the Assemblies folder. Then, the upstream projects have a References folder, with an entry for each 'subsystem' that needs to be referenced which points to the Assemblies folder for the subsystem. Bin is not stored in our source control. (we are using TortoiseSVN)
I use references and set their property to "copy local" or something like that. You can reference other projects so the dll is rebuilt and imported automatically to your build directory. For asp.net, I guess you could use the strategy of having an "assemblies" directory and set their build action to "copy to output directory", and "copy if newer". If that is not available in asp.net, you could use a post build script to copy the files from assemblies to bin. And if all else fails, I think it's possible to declare that directory as a dll search path or something in the config, but that's less than ideal because it breaks the "standard" directory structure of an asp.net site...