I have to change some used libraries quite a lot. I am storing the changed libraries in a new folder. To use these new libraries I have to change the references in projects which uses these. Because my solution contains 15 projects which have to use the libraries, I have to change the references in every project. But that really s**! Is there a simple way to just change the reference path in a single project and the other projects are referencing the references? So that I have to change the references only once?
Use reference path tab in project properties. http://msdn.microsoft.com/en-us/library/6taasyc6.aspx
If the library is in your solution, you can add it as a "project reference" in all the projects that depend on it. Thus, changes will automatically be accessible as soon as the library changes.
I don't think such a 'reference to a reference' mechanism exists. You can ease your pain a bit by opening your project in Notepad, copying th desired reference string and then using some third-party search and replace software which can traverse through all your projects and change the reference for you.
I would create a shared library folder.
/src
/lib (shared folder)
/mylibraries (for ease of use copy your newest libraries here)
When you decide you are going to increment you can move your old libraries to a new folder and replace them with your new libraries.
/src
/lib (shared folder)
/mylibraries (copy from here)
/3-1-2011 (to here)
Related
As the screenshot demonstrates, I have a project SampleApp that uses the namespaces EDAM and Thrift. I want to replicate the functionalities of SampleApp to another project.
Do I have to include the two projects (EDAM and Thrift) in my other project? Can I just copy the folders instead of including the actual project files? Can I just convert them to some sort of DLL or something?
You definitely should add references to the EDAM and Thrift projects from the SampleApp project.
To do so, follow these steps:
Right click the 'References' folder in the SampleApp project.
Select 'Add Reference...'
On the popup, go to the 'Solution' tab.
Select the EDAM and Thrift projects.
Under no circumstances should you just copy the files.
Don't copy the folders, just add references to the projects. Even if the projects are class libraries you don't want to copy the DLLs, instead you should add references, just in case your DLLs are updated:
How to: Add or Remove References in Visual Studio
If the "other" project is in the same Solution, you should be able to reference EDAM, Thrift and even SampleApp from that project much in the same way you set the references up for SampleApp.
If this "other" project will be in a new solution...I'd have to do a little research and testing.
Visual Studio project references are equivalent to referencing an assembly directly, but it has a great advantage: when you build a project, Visual Studio take cares of building its dependent projects too.
In addition, Visual Studio will prevent circular references.
There're many other pros, but it's a good summary.
Copy-pasting the code files isn't importing a namespace: this is duplicating code! And referencing the assemblies directly is a waste of time and features!
This has probably been posted before, but I'm not sure what search terms to look for!
Quick explanation.
I have code that is shared between a few projects. This code is still work-in-progress itself. The issue is that whenever I need to update this code for whatever, I don't want to have to do it 3 times, this will become a nightmare.
Is there a way to add it to a project, without copying it into the project folder?
i.e. I want the shared class to be linked into my 3 projects as
C:\code repository\sharedclass.cs NOT \eachproject\bin\sharedclass.cs
Do I have to create it as it's own library project? It would be much better if the compiler could compile it as 'external' code.
Cheers.
As others have said, you can simply right-click on your solution in the solution explorer, select Add > Existing Project, and browse to the common project's .csproj file, and it will be included in the solution from its original location.
There are two problems with this however, which may or may not be an issue, depending on the size of your team:
The common project will be included in each solution with a relative path to the solution file (i.e.: ...\CommonProject\Common.csproj). This means all developers have to have the same working file structure or they will get errors when they try to open the main project.
In the scenario that the common project is referenced by multiple projects (say two - A and B) and a developer working on project A has to make changes to the common project as part of their task, there is no way for that developer to know if the changes they have made will break project B without them actually checking out project B and compiling it. As more and more projects reference the common project, the risk of this happening increases to the point where it becomes unmanageable.
Again, as others have said, there is no 'correct' way to do this. However, the approach I have taken is as follows:
Use continuous integration such as Cruise Control to manage the building of the projects and put the common project as a standalone project on the server.
Create a directory under your source control to house built common DLLs. Have this directory checked out on your build machine and whenever the common project builds, it copies the output DLL into the DLL folder and commits these changes to source control.
Use environment variables on all developers' machines and the build server to control the location of the common DLL folder and reference the DLLs using that variable rather than the hard-coded path. (i.e.: rather than C:\Source\MyCommonProjectDLLS\Common.dll, use $(MyCommonLocation)\Common.dll with the variable 'MyCommonLocation' set to C:\Source\MyCommonProjectDLLS)
For any project which references the common DLL, set up a CI trigger on the build server for that project to watch the common DLL folder. Whenever changes are committed to it, the build server should then build all consuming projects.
This immediately lets you know if you are committing breaking changes for any other project. The only drawback is that, in this model, consuming projects are forced to take updates to the common DLL as soon as they are made. An alternative is to version the Common DLL from the source control revision when it is built, and place each version in its own sub directory under the common DLL folder. So you would end up with:
Common DLLs
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236
And so on. The advantage of this is that each project can then choose when to take updates to the common DLL by simply referencing the new version of the code. However, it cuts both ways as this can mean that some projects are left with older versions of the common code for longer than they should, which can increase the work involved when the time comes to finally bring in those changes.
Yes.
You can add a project from anywhere on your hard drive to a solution. So put the shared code into a class library and add that to your three projects.
Microsoft has been supporting an open source project which comes built into VS now, its called NuGet, you can output your shared project as a nuget file and consume it in your other projects.
It will actually deploy all the files you specify in the package upon build.
This is how .Net supports dependencies now. You will notice that even things like EF come through NuGet packages. You can even host it for free on places like MyGet.org I use this and it works quite well.
http://nuget.org/
I use git submodules to achieve this.
Create a new git repository for each module (project) that you want to share between solutions. I usually also include unit tests for that project in a separate project but in the same git repository.
Add a submodule to the git repository of the solution that will use the shared code. Adding a submodule creates a link to a specific commit of an external repository. When the code in the submodule is updated you will be able to pull the updates to your parent solution, which is essentially the same as updating the reference to the submodule commit. I find that the process is easier to visualise using an app like SourceTree.
Adding the submodule and pulling the latest commit will create a copy of the shared project inside the parent solution folder. Import the project into the parent Visual Studio solution by right-clicking on the solution and selecting "Add existing project".
Add a reference to the shared project in the other projects that will be using it by right-clicking on the project and selecting "Add Reference" and finding the shared project in the "Solution" tab.
Now that the shared project is included in the solution you will be able to push and pull changes to the submodule and these changes will automatically be incorporated into the solution. You will also be able to see the changes in other git repositories that reference the submodule.
Yes, put the code which need to be shared in a separate class library project, build it and reference the DLL created from this build into your other projects.
It is better to extract common part into a separate project library and add reference of this project to all the solutions/dependent projects.
Otherwise you can Add code/file/item as Link.
Our project has a lot of external DLLs, most but not all of which are 3rd party DLLs.
Currently we do not have these DLLs included in our project. They are included in SVN and given a path to our build output directory. So, after building our project the neccessary files are there, because of SVN, but the project itself has no knowledge of them.
My feeling is that we should have a folder under the root of our project named something like Dependancies or ThirdParty with all of the DLLs included there and set their build event to copy to the output directory. They would exist in SVN as well, but in the same structure as the project, not in the build output directory.
The project itself only references one of these DLLs called CommunicationProc.DLL. The CommunicationProc.DLL then references all of the other DLLs. We have numerous DLLs to support different types of radio. So not all DLLs will be used, but any one of them may be used depending on the radio type.
As to whether or not the DLLs should be included in the project we have differing opinions internally, some of the team beleives they should only be in SVN and not part of the project itself.
Of note is that this are not .NET DLLs, most are old C DLLs.
What is the accepted practice? Can someone please provide me with a compelling arguement one way or the other as to whether to include them in the project or just SVN?
Its better to have them in a folder on source control and then copy them over to the debug folder on build event. This way you can manage their versions. If a newer version of some dll comes then you can replace the old one and put some comments with check in. Also if you are working in a team, then instead of copying files from debug folder to each team member, you can let each team member to use the same set of dlls from source control. If you are developing some control and want your customers to use that control then its easier for you to have a set of dependent dlls some where so that you can give those to your customer along with your .Net dlls.
I had the same issue with some un-managed dlls and ended up putting them in a folder so that all the team members have the same version of the dlls. Hope this helps.
I include a project that has no code but contains a folder where all the external assemblies and their dependencies are kepts. For each file set the Build Action to None and Copy to Output as Do Not Copyp. The project then references the binaries from this location. In your other projects, reference this special project. When you build, because the special project is referenced and it references all the needed dependencies, the binaries are copied as needed.
If you do not want a special project, still create the folder in your main project, added the assemblies, set their properties, then reference the assemblies as needed.
This gives you complete control over the versions and output, and more importantly, it is simple.
I'm using subversion and nant (and visual studio IDE)
I've been following the suggested project structure at http://blog.jpboodhoo.com/NAntStarterSeries.aspx which advocates self contained subversion directories where a developer can do a checkout and immediately build a project in a single step.
My repo structure is like:
/Repo
/MainProject
/trunk
/doc <-- documentation
/lib <-- binary-only DLLs
/src <-- source code for MainProject
/tools <-- holds tools like nant, nunit, etc
...
/ClassLibrary1
/trunk
/doc
/lib
/src
/tools
...
/ClassLibrary2
/trunk
/doc
/lib
/src
/tools
What's not clear is how to structure a project that has class libraries which in turn reference third party library dll's themselves.
Currently, I have a main project with a working directory like
Example:
/MainProject
/build
/lib
/src
/MainProject
/ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src
/ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src
/tools
...
When building MainProject, I compile the class libraries and output the dll's to the build folder. However, the class libraries themselves have 3rd party binary-only DLL's that they reference.
My questions is in order to build the MainProject I have to somehow get the 3rd party DLL's from the class libraries into the build output. How do I do that?
Thoughts:
1. Should I store copies of these 3rd party dlls in the MainProject's lib folder?
2. Or should my svn:external reference be to the trunk of the class library project rather than the src so that I can access the class library's lib folder?
3. Should I use the subversion 1.6 feature of svn:externals to individual files?
Personally I bring in the trunk of the referenced libraries.
(Actually, I bring in the root of a tag, but that's beside the point).
If you keep a separate copy of the required dll's, then you're not really allowing the referenced library to determine what it needs for itself because all that logic is duplicated in the project. The same thing happens if you use multiple externals references or file externals to bring in the code and the dll's.
My principle here is that - the library knows what it needs, a single external reference to the library can get that library and everything it needs.
That way if you change the library's references, you can be confident that any and all projects will just pick that up. (if the IDE doesn't support this, that's the IDE's problem, not subverion's). You can also be confident as a project that if you change the version of the library you're pointing to, you'll automatically get the right references as well, and don't need to go debugging build failures to work out what's gone wrong.
Should I store copies of these 3rd party dlls in the MainProject's lib folder? I prefer to store any external libraries in a binaries directory under trunk but next to source...or call it references, dependencies, etc. This then allows any developer to get latest and all that is needed will come down. It doesn't need to be part of the project per se. It just needs to be accessible when the build is performed.
Or should my svn:external reference be to the trunk of the class library project rather than the src so that I can access the class library's lib folder? I don't prefer this approach as it makes the process of getting a new developer up and running more convoluted. I think an assembly can go into its own repository when it has a level of importance on to itself. But I would never reference its output. It should have a build process wrapped around it that promotes a mechanism to "deploy" the output to the above references or dependencies directory. However automating the deployment like that might be fraught with issues. It would be better if the assembly had its own process around it. And when a new version of the assembly were released it would be manually embraced by a developer on the project that needed it. They could then test it, accept it, and place it into their build process. Obviously if that assembly changes on a daily basis some automation may be required.
Should I use the subversion 1.6 feature of svn:externals to individual files? No. I prefer to keep a project/solution as a self contained entity. Having tenticals spread out all of the place makes dependencies more painful. Keep silos as hard as possible...bring new things in as manual as possible...or as manual as the frequency that things change will allow.
I had a similar need and found a short-and-sweet answer in TortoiseSVN's documentation :
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-howto-common-projects.html
I've just started using Team Foundation Server and have added a new Solution that contains a project of type class library. I need to add a reference to the new class library project to an existing class library (dll) that we have created. What is the best way to do this? I've noticed that if I try to add it from the original location as an existing dll, it keeps the original location of the dll. I think what I want is to actually copy the dll to the new project, and add a reference to it locally - but I can't figure out how to do that.
Write a MSbuild/Nant script that build's and copies the dll to a common lib directory. Then reference the lib\foo.dll in 2nd project. Also create the build order.
Can you include both the old and new projects in the same solution? If so, you can reference the project directly (primary artifact) instead of the .dll output (secondary output). This 'just works' when you need to build multiple configurations, such as debug, release, etc.
If that dll is something that will be shared among different libraries and applications, you may want to consider putting it in the GAC. This will also help avoid versioning issues of putting it in a common lib directory (although you could just put folders in the common lib directory for different versions)
MSDN article on the GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx
Another way that doesn't involve copying the whole project or messing with the GAC would be to:
Add a reference to the DLL to your project
Open the references folder in your project
Right click the DLL -> Properties
Find Copy Local and set it to "True"