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
Related
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
I have several Visual Studio solutions/projects (some VB, some C#) that all reference a common DLL at design time. This DLL does not have to be copied to the output folder as it is only needed while writing code. Every few months this DLL will be updated to a newer version and all of my projects need to reference the updated version.
What is the best way to handle this?
You have to use a Shared Assembly, shared in GAC (Global Assembly Cache).
Say, you have programmed a class, a piece of software, whatever you have, and you want to make it a shared assembly.
First you make it an assembly by creating a new Class Library Project in VS and transporting all of the code to that project. Don’t build/run it yet! Note that we just transport the code but the assembly (the .DLL file) is not actually made yet, because we have not built the project yet.
Before building the assembly, we have to create/share a key by which the assembly is known, in 2 steps:
a) create the key by executing the cmd below in VS cmd:
sn -k "C:[DirectoryToPlaceKey][KeyName].key" b) share it by adding the attribute below to the AsseblyInfo.vb/cs file in the properties folder of your Class Library project:
In VB.Net:
In C#:
[Assembly: AssemblyKeyFile("C:[directory containing the key file][KeyName].key")] (just copy and paste this into the AssemblyInfo.vb/cs file, but write your directory and file name instead).
Now, you MAKE the assembly by building the project. Just build the project (just press F5 once, at least!). By doing so, the .dll file we need (the assembly) is created in the “bin” folder in the same folder of the project.
Now we share it by Copying the .dll file into the GAC (Global Assembly Cache: it’s where all the assemblies are gathered together. The directory is: “C:\windows\Microsoft.Net\assembly\GAC_MSIL” but you don’t need to know that since the tool below does that for you~) by executing the command below in the VS cmd:
gacutil -I "C:[PathToBinDirectoryInVSProject]\myGAC.dll"
YOU'RE DONE! You may now reference and use the shared assembly from all your applications, and whenever you want to update, just update the shared assembly.
Hope that helps!
You can create nuget resources, and use Nuget Server (Lastest version of teamcity support it) - and all updates w'll be handled by nuget.
Other approach is to create common folder and all project point's to dll in this folder (relativly) in this case you need to udate dll in one folder (after rebuild solution dll'll be updated automaticly)
Ofcourse you can allways install dll in GAC (Global Assembly Cache) this is handled by tool called gacutil.exe (in net is lot of example how to handle it).
For a long time looking for a way to manage references, I haven't found any ideal way.
The main problems are:
1-) Should I include all projects that I use in same Solution and reference the Project? Or reference just the dll file?
2-) If I should reference dll file, the best way is to create a ReferencedAssemblies inside each project or a main folder at svn root?
3-) Its ok paste and reference dll´s inside bin folder of my project?
4-) Its ok add and commit dll´s inside bin folder of my project? This way when a new devoloper checkout the project, it will compile perfect, but isn´t default behavior of visual studio, all source controls ignore bin and obj by default, just adding .refresh files(for web-site project)
Someone can help me?
1) If you include projects in your solution that are already checked in somewhere else, you can change the SVN binding for that project at the solution level in Visual Studio. (File > Source Control > Change Source Control). You would change it to point to wherever it's located in your SVN repo.
2) If you have a lot of developers on different machines all wanting to use the same libraries, it's probably easier to have a common place for all your third-party libraries/assemblies. There's no point in having them copied all over the place in your SVN repository.
3) No, it's not usually ok to do this. I would avoid it (unless somebody has a valid reason for it).
4) Never commit your bin folders. The default behavior is such for a reason. The .refresh files are byproducts of the old Web Site projects and they are fine.
1) In the typical scenario yes, you should reference all projects that you own. But you should make a decision according to frequency of changes made to referenced projects. For example if you have an open source library it is better to include it as an assembly, cos you probably will not change this code frequently.
2) Typical approach is to create separate single directory at SVN root and place assemblies there in different sub-folders according to assemblies type. Here is how my current folder looks like:
3) No, it is better to reference assemblies from some other from bin folder. All referenced assemblies will be copied to the bin while building process. Also note that the purpose of *.refresh files in the bin folder is to prevent you from having to copy new versions yourself.
4) No, you should never commit your bin folder cos you can rely on *.refresh files for WebSites and just forget about this problem for other project types.
1) I'd argue it depends upon your particular situation, especially since Visual Studio is pretty flexible on what projects are included in solutions. (It's not tied to a directory structure.)
We have a couple applications that have one solution with a number of projects contained within (for each 'piece').
2, 3, 4) For referencing and including files within a project, why not just use the functionality built into Visual Studio? Adding references in this way adds the items to your csproj (vbproj) files.
(Based on my research, if you're not referencing a project that's part of the solution, put the DLLs in a directory everyone on the team can access and use that when adding the reference. In the project file it ends up looking like this:
<Reference Include="Elmah">
<HintPath>\\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>
)
This also means that you don't have to commit DLLs; if anything changes the project file will be updated accordingly.
(I'll admit, I'm unsure about that last point. I've seen a lot of people check in external libraries, like ELMAH. I generally follow those who tell you to ignore the bin directory entirely.)
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.