My Question is, When i am building any solution all the dll's are copied to bin folder. Can we split this dll's with different-different folder's once build is completed? i.e I am having some third party dlls and some other dlls like DevExpress dll's so i want to separate all of then in thier specified folders.
Please dont suggest for manual copy paste. Developers is pulling code from git hub once it is build then folder structure can be made automatically.
Please suggest if we can do with Post-Build Event.
Thanks in Advance.
You could copy files through Copy task after build. For example, (add to the end of your project file):
Related
I have the following dir. struct
$/
TeamProj1/
Solution1/
<Solution and files etc>
TeamProj2/
Libs/
LibSolution1/
<solution and files etc>
External/
ThirdParty.dll
Solution1 has a project reference to LibSolution1, and has an assembly reference to ThirdParty.dll.
When I do a fresh check out of Solution1 via File->Open from source control TFS correctly checks out the LibSolution1 files, but not the third party dll.
If I manually check out the third party dll everything builds.
How do I force TFS to check out the correct third party dll files?
I can think of two possible methods but don't particularly like either.
1) I could add a libs folder to Solution1 and add the dll there. Then the dll will be checked out when solution1 is checked out. I don't like this method though because there are solutions in addition to Solution1 that will use the third party assembly, and I want to maintain only a single copy of the file.
2) I could create a "dummy" ThirdParty project/solution and add the files to that solution, then add the dummy project to solution1 solution. Then when I check out solution1, it would see the dummy project and check it out along with all the associated files (being the third party dlls)... but that seems unnecessarily complex.
Isn't there a way I can instruct TFS to simply check out the required file?
This solution here is a variation of your option 1 but without having to maintain multiple copies of the DLL's.
Add a new folder to your Solution1 (say Third_Party_DLL). Right CLick the folder -> Add existing item and instead of adding the DLL's physically here (create a link to these third party DLL's from the location where you have saved it). Now after adding the DLL links in the folder, add reference to the DLL's in your project from this folder (Third_party_Dll).
Now when you are getting the latest of the solution file, it should get your DLL's too. I havent tried this out myself for Dll's but have done this for maintaining a single copy of the AssemblyVersion file and it worked well. Try and let me know.
Add Vs Add Link
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
I have a couple of different solutions, in which some projects may depend on output from projects in other solutions. To manage this, I've been copying dll files from the /bin/ folder in each project to a shared library location after build, and then copy/reference them from there to the dependent project.
However, as the library solution gets larger, this tends to become unmaintainable. Too much of my time is being spent traversing solution directories in Windows Explorer looking for /bin/ folders, and trying to figure out which one, or which ones, of the dll files from each one I need.
Is there any way to give Visual Studio a hint that I want all projects in a solution to have the same output directory? For example, a /bin/ folder directly under the solution folder, where all projects put their output.
If possible, I'd like to achieve this without hard-coded post-build events that copy the files, since that will fail if a project output changes file name, or adds another file. I'd rather like to change the location of the actual output directory - the location of $(OutDir), if you will.
I know you said you don't want to use post build events, but your reason as to why not intrigued me. It sounds like you might be hard coding the name of the .dll in your post build event. That can easily be avoided.
xcopy "$(TargetDir)*" "c:\common\" /Y
The * would just cause everything in your bin/Debug/ folder to get copied to your common folder. You could also just copy dlls if you want. Or, if you use $(TargetPath), you'll copy just the 1 dll that is the result of the project, and not any other related dependencies.
UPDATE
The way we do it is each projects entire bin folder is copied to a subfolder. Suppose you have 2 projects, WebUtil and HtmlParser, where WebUtil depends on HtmlParser. For both projects, use xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y. This will create c:\common\WebUtil\ and c:\common\HtmlParser. In WebUtil, add a reference to c:\common\HtmlParser\HtmlParser.dll. There will now be 2 copies of HtmlParser.dll in c:\common.
c:\common\HtmlParser\HtmlParser.dll // the most recent build.
c:\common\WebUtil\HtmlParser // what was the most recent build when WebUtil was built
This has all kinds of advantages. If you change the API of HtmlParser, WebUtil will continue to work, since it will have the older HtmlParser.dll until you try to rebuild WebUtil (at which point you'll get build errors because of the changed API).
Now, if a 3rd project got in the mix that depended on WebUtil, and you're using some part of WebUtil that exposes classes in HtmlParser, then you'll need to add a reference to both projects from your new project. When you add a reference to HtmlParser.dll, use the one in c:\common\WebUtil. You do this because you're only including it as a necessary requirement of WebUtil. Now you'll always have the version of HtmlParser.dll that matches your current version of WebUtil.dll.
I hope that makes sense. It can definitely be a tricky thing to manage. Just wait till you have to start pulling down all your dependencies using svn:externals =P
You can set the output directory in each project properties.
Right click on the project, select Properties
For C#, it is one of the Build property page, under Output, Output directory.
In VB.Net projects, it is on the Compile tab, in the textbox at the top.
I'm working through installing the N2 content management framework in an ASP.NET website project.
The instructions at http://n2cms.com/Documentation/Content-enabling%20an%20existing%20site/The%20first%20content%20class.aspx recommend I create a lib folder to hold the required dlls. The very next step asks me to reference those same dlls - which will presumably add them to the bin folder! Thus my project will contain duplication copies of the dlls.
Can anyone suggest why this recommendation has been made?
Thanks
David
The project will not contain duplicates. The bin folder is where the output goes, but it is not considered part of your actual project and is not checked into source control.
By placing the DLLs in a lib folder, it makes it easier to distribute them with the source of your application and ensures that anyone else who gets a copy of your code, whether you send it to them or they grab it from source control, has the necessary DLLs to run the application. It also ensures that they are use the same version of the components that you used to create the software. If the DLLs require licensing, it can be a different story because anyone who wants to compile the project would need the licensing component for the DLLs installed on their workstation.
Basically, the main benefit I see is that it keeps all components used by your code in the same place, making your project one whole unit.
If you add the DLLs to the bin folder, then one day decide to clean your project, they will disappear... So it's good practice to keep your reference DLLs out of the bin folder.
Actually there's quite a few ways the DLLs can be accidentally removed from the bin folder. Just think of the bin folder as a transient location, the contents of which can be refreshed at a moment's notice.
During the build process all relevant files will be copied to the bin folder, including config files, content files marked for copy to the output folder, and of course, any referenced DLLs marked for Copy Local.
If the duplicate locations bother you, you can keep the DLLs in another folder, and just add the containing folder path to the PrivateBinPath of the current AppDomain, which will ensure they get loaded without requiring the Copy Local property.
I am working on a VS solution that utilizes the post-build events to copy files into a deployment project that packages the files. Does anyone know if there is any best practice in how to move files around to place in an MSI?
As long as you are sure that you never want something else that the latest release build in your package, you are fine. But if you want to be prepared for "repackaging" scenarios, for example, to have an option for easily exchanging a single file in an existing package, you should consider to separate the build process from the "copy to the deployment project" process.
As long as you copy all the dlls, exes, help files, icon files, resources ( but not .pdb), you are OK.
Why no pdb? Because pdb is debugging file, and it is there for debugging purpose. So in your release build, you don't need to have them.