My situation:
I have a solution A with hundreds of projects,
Some of projects are class libraries and are referenced from other projects.
Now I want to create a new solution B which will consist of subset of projects of solution A. I start by adding the first pre-existing project into this new solution B. This project is referencing couple of class libraries from solution A. Therefore it is logical that these libraries cannot be found and I cannot build. Of course I could add all the referenced projects manually into the new solution B but that would take quite a long time, considering the total amount of projects that I need to add.
Is there some built in Visual Studio feature that can take care of this on my behalf? I.e. I will be offered an opportunity to import all the referenced projects at once and the B.sln file will be updated automatically.
I also have a ReSharper extension but I couldn't find such feature in there as well.
EDIT:
Some more detail on what I am trying to achieve. A.sln has lots of application projects and literally hundreds of class libraries. I want to create a new B.sln for one particular application project from A.sln and only add the class libraries that it is referencing, directly or indirectly... But the dependencies can go up to 15 levels deep so manually removing projects from original A.sln to create B.sln is really not suitable for me as I would have to carefully consider each one of the projects that I would be manually removing from the original sln file, subsequently reviewing the csproj files to find whether the application I am interested in does not indirectly depends on them via one of its direct references.
Copy paste your current solution file and start with it. Open it in new Visual Studio Instance. Remove your projects one by one. Instead of adding new projects, removing unnecessary ones will be more easy for you. As far as I know there is no such feature in Visual Studio as you want.
Removing will be more easy since projects are already there. Do not use Visual Studio to remove project but open sln file in suitable programmers notepad. Your projects are added to sln file as below lines.
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example.Integration.App1", "..\Example.Integration\Example.Integration.App1\Example.Integration.App1.csproj", "{E3977144-AFBA-451D-894C-1F89AA008041}"
EndProject
Removing such lines will be more easy if your projects has naming convention.
The best way to port references from an existing project that I've found is to generate a template for that project.
On the File menu, click Export Template. The Export Template wizard opens.
Choose project template and move through the wizard
Click Finish. Your project is exported into a .zip file and placed in the specified output location, and, if selected, imported into Visual Studio.
Now, when you setup a new project for solution B. You'll be able to choose the project template from A and all the file structure/references are preserved.
Ref: http://msdn.microsoft.com/en-us/library/vstudio/xkh1wxd8%28v=vs.100%29.aspx
Related
Let's say I have 5 or 6 projects in my solution. There is a file called fileCopyHelper.cs that basically copies files from one folder to another. I need this file for a lot of projects in the solution and I don't want to keep redefining it in every project? How do I do it?
I tried adding a .cs file to the solution and Visual studio grouped it into Solution items folder. However I'm unable to access the classes defined in this file in my projects because Solution items is just a folder, not a project, so I can't add a namespace reference from other projects.
Add a new project to your solution, and select the class library type. This gives you a single place to add code that will be shared.
Reference the new project in whatever other projects in your solution need access to the code.
Your setup might look something like this, where the fileCopyHelper class is party of ClassLibrary1, which is then referenced and used in the main ConsoleApp1 application:
I have two C# projects in TFS and I want to add them to another solution (that is in TFS as well), how to do this correct?
Tried to check out these projects and open the target solution > click "Add" > "existing project" but VS doesn't recognize this projects as they are under Source Control.
All I need now is:
1) Get copies of 2 projects that are already in Source control
2) Add them to my solution
3) Make changes in these projects
4) Check-in changes without affecting the original versions
Let's call your two projects your framework. You should branch your framework and then link in your new solution to the appropriate branch.
Branch.
In Visual Studio, Team Explorer, browse your code collection
then right click on your framework source root folder and select "branch" .
Then checkin your new branch.
Link
In your new solution, click "Add Existing project..." and select the projects from the branch you just made.
The branched code basically is a full copy of your framework source code. But this copy is logically linked to the original one (for the TFS system). Nothing will be altered in the original one when you alter the branch, but you can merge selected changeset if you wish.
Folder structure
There are many possibilities about how to structure your TFS collection. My advice is to keep your main developping framework code in a Trunk folder and to have, at the same level, a Branches folder with all the versions in it. In the image above, there is only one branch made yet (named after a released version of my project to do hot fixes if needed, but this is just an example).
Merge
Then, you can merge changes if you want from the branch to the trunk (no obligation, just to avoid manual-error-prone code copy).
The documentation is here.
Sharing of code between different solutions is an ati-pattern that should be avoided.
If you have two projects that are required in more than one solution you should build and version them independently.
1) Split the two projects out to a new solution and folder structure.
2) Build and version your two shared assemblies
3) package both assemblies as Nuget packages and store on a network share or ProGet server
4) change the references for your two other solutions to use the new Nuget Package
5) create an automated build to refresh the Nuget package as you change the code.
You then have a shared component that you can make deliberate changes and deploy to your shared location. Each solution that takes a dependency will then notify you when the code is changed.
If you want to have two independent copies of you projects, then Askolein solution is your best bet.
However, if you want to reference the same projects from many different solutions then I think the following should work (some of it you listed already):
in your workspace map and download directory that contains all projects and location of both solutions. So if you have $/tp1/solution1 for existing solution $/tp1/solution1/proj1 for project and $/tp1/solution2 for new solution then you map $/tp1 and best download all files under it
now open solution2 (the one that you want to changes) and click Add->Existing project. You should be able to select projects as they exist on your local disk. You may need to "Add solution to source control" just to add your solution file. However projects are already in TFS and all your operations should not change their content (projects may be in many different solutions)
Good luck!
We have one master project that creates a single DLL with FEATURE_1, FEATURE_2 and FEATURE_3 as three conditional compilation symbols that enable those respective features.
MyLib.dll => has FEATURE_1, FEATURE_2 and FEATURE_3 compiled in
We now wish to have the same master project spit out 3 different DLLs as follows:
MyLib.1.dll => has only FEATURE_1 compiled in
MyLib.2.dll => has only FEATURE_2 compiled in
MyLib.3.dll => has only FEATURE_3 compiled in
At present we build within VS2013 and those compile constants are defined inside the .csproj file (within the <DefineConstants> </DefineConstants> tags), which hard-codes them.
Is it possible to pass them via a command line so we can still maintain one master csproj but build the 3 different flavors in the RELEASE configuration just by changing the command line (eg: gcc's -D<buildFlag> style) ? The solution has other projects and they're designed to work with the RELEASE configuration. I'm also open to any other technique that is easy to use and maintain.
We're really trying to avoid creating pseudo-projects or affecting other projects in the solution (21 projects in the solution) - seems like an overkill/hackish for something very simple.
I haven't done anything with the command line, but to solve similar problems, I created separate projects (that define the Framework Target and any conditional compilation symbols), and then add all the project files as LINKED files. In this way, I only have to modify a single set of source files, but each project compiles into its own DLL.
To add a file to a project as a linked
Right click the project and click Add Existing Item...
Select the file (or files) you want to Add.
Instead Of clicking the Add button, click the arrow next to the Add button, and click Add as Link.
I'm not sure if this will work for your case, but it sure has saved me lots of time when developing libraries for different .NET framework versions.
Is it possible that you have a complete turnaround?
Instead of defining all features in a single library and then disable some of them, you can create individual projects for each features, and then at packaging phase merge the smaller assemblies into a single one.
Microsoft has ILMerge, while ILRepack is an open source alternative,
https://www.nuget.org/packages/ilmerge
https://www.nuget.org/packages/ILRepack/
Then you are free of conditional compilation, which is too difficult to manage, and the complexity is moved to your packaging scripts, which can be easily managed and checked into source code management.
Need to add two same name .csproj class libraries in my solution.Have two project but unfortunately those project class libraries names are same,like: Hello.csproj.I try to add existing project on solution then show me error
http://blogs.msdn.com/b/ansonh/archive/2006/09/27/774692.aspx
from above url I learned how to use same namespace dll on same project ,but I need help how to use same classlibraries on a solution
if have any query please ask,thanks in advanced.
Note:ok people want to know the reason,i have two project on Autocat 2005 and 2010,now want to merge those project on one solution,2010 update base on 2005 so class libraries are same,but i need to use both of them.So problem arise and seeking help.
You can have projects with the same name as long as they are already created in different folders and they are in different solution folders. If the projects are already created, do this to add them to your solution:
Add your first project to the solution.
In Solution Explorer window, right click your solution and select Add->New Solution Folder
Give a name to the newly created folder.
Right click the folder and select Add->Existing Project
Navigate to your second project and double-click the .csproj file.
You're done.
If you really must do this, then ensure the second project has a different name, and then change the namespaces of the classes in the second project (normally the project name comprises the first part of the namespace - just change that part). The classes will still be identical internally, but because they have a different namespace they will be distinct entities. This will lead to very smelly code though when you start mixing them up in the ClientApp - to avoid confusion make sure you always refer to them by their full namespace (i.e. do not have a using xyz.myclassname; statement at the top of the class file that uses them).
Maybe you want to run two (almost identical) instances of the same service or something, but as mentioned it is hard to think of a genuine reason why you would need to do this. If you are looking to have two identical looking instances but different implementation then you will want to use interfaces instead.
Edit: Visual Studio will not allow you to have two identically named projects, and you are playing crazy games if you change a project name but don't change its project GUID (in the .proj file and the .sln file).
The simplest thing for you to do here is to create a new empty project in the solution explorer, right click on it and Open folder in Explorer, then copy the class files from the original project to the new one, then back in the solution explorer choose Show all files (little button at the top of the solution explorer), then select the newly added files under the new project, right click, Add to project. (These menu options are from memory, they should be roughly right).
I have two very long and detailed .csproj files.
I want to combine them into one.
I used text comparer but the items are not in the same order
and it's hard to isolate differences.
How would you recommend to combine them?
(they have compile, include, post build and after build events)
edit:
I want to merge 2 unrelated projects with some common dependencies
Copy the files from project 1 into the project 2 folder. Then turn on "Show all files" so you can see the files that aren't in the project. Then right-click each file and choose "Include in project".
I would probably do most of this in Visual Studio. You can either drag the files you need from one project to the other, or you can copy all the files from one project folder to the other in the file system and turn on "show all files" in the solution explorer to show which need to be added. You will then need to align the namespaces. The Class View window can help identify types which do not fall inside the right namespace. A refactoring tool like Resharper can also help fix up the namespaces.
If you have explicit pre or post build events in each project, I would use the VS GUI to show these and manually combine. If you have custom build targets/tasks in the files, I would isolate these in a good text/XML editor and manually union them as required.
The other thing you will have to do is to add references to the final project which it did not originally require but were required by the other project. It should be quite quick to identify which references need to be added, by attempting compilation and inspecting any errors.