What is the best strategy when having multiple solutions where some projects in a solution make a reference to an assembly of another project in another solution.
- Solution 1
-- Proj1
-- Proj2
- Solution 2
- OtherProj 1
- Solution 3
- FooProj1
- FooProj2
For example if OtherProj, FooProj1 and FooProj2 use Proj1 or Proj2 assemblies.
Now I have to build for example Proj1 and manually copy/paste that assembly to a solution folder in Solution 2 and Solution 3.
I can't reference directly, because that would use a local path and if I check in via source control (TFS) my colleague receives my local path (that is why we copy/paste in the solution folder so that the path is always relative).
What we were thinking of is adding a post build event and copy the assemblies to a shared folder on a server \myserver\assemblies\relaase\Proj1.dll and then reference to these files in our solution/project.
Would that be a good strategy, because it would work also with source control, or are there any other strategies to work?
(Something exists like Shared Projects in Visual Studio, but I think that is more for a single solution but multiple platforms instead of sharing around)
You should publish the output of each project/solution as a Nuget Package and take dependencies on those packages.
It is very easy to have the output of your Project or Solution packaged as a Nuget Package with most of the capabilities built in. A NuGet Repository can be a Network Share or you can use a hosted service (MyGet, VSTS/TFS, others).
The VS extension, NuGet Reference Switcher is one solution for this situation. From it's description:
NuGet Reference Switcher is a Visual Studio extension which automatically switches NuGet assembly references to project references and vice-versa. This is useful when developing applications which reference own NuGet packages.
Here is the VS 2015 version.
Here is the VS 2017 version.
Related
In Visual Studio 2019, in a .NET Framework (not .NET Core) console application project, how do I add NuGet packages so that they show up in the "Packages" section of a "Dependencies" instead of just as "References" with other assemblies? That is, I'd like to get this (which is from a Microsoft example app)...
... instead of this (which is what I have in my app after adding Newtonsoft.Json and MSAL using the NuGet package manager tool) ...
Notice, in my app, there is a "References" section but no "Dependencies" section, and the packages are mashed in with the other references. The only thing I could find to try was to right-click on References then select the "Migrate packages.config to PackagesReference", which yielded this ...
(StackOverflow bug? When I try to add a third image, it shows some totally random image in a different language. What the picture shows, though I can't get it to add, is the same "References" section except that the Json and MSAL references have a different icon.)
... which is closer (the packages are now "references", I guess) but there is still no Dependencies section with partitioned Assemblies and Packages subsections.
Assuming the MS example is doing it "right" and that I am doing it "wrong", how do I get from where I am to where they are?
Ah! I think I found the answer at Visual Studio 2017 References vs Dependencies. It appears I need to use a different project type if I want the newer style project file.
When using a local NuGet repository is it possible to set up Visual Studio so that when trying to navigate to implementation of some symbol which is part of a local NuGet dependency it would open the actual source code of it (instead of just decompiled source)?
I have the sources for dependent NuGet projects cloned locally into the same folder. Preferably I'd like a solution that does not involve creating a global solution that includes all the projects.
I have a C# solution consisting of different projects.
MySolution
+-- Project1
+-- Project2
| +-- packages.config
+-- Project3
+-- packages
| +-- System.Linq.4.0.0
| +-- System.CodeAnalysis.CSharp.1.3.2
I have NuGet dependencies as you can see.
Declaring dependencies, installing them
My point is that Visual Studio has created packages.config with the list of the dependencies I need inside the project that actually needs those dependencies. And I guess this is fine.
Also, Visual Studio installs all the packages in a folder which is in the solution folder. This is fine too because projects like Project1 (which depends on Project2) need to refer those packages as well.
Questions
My doubts are on this arrangement:
Isn't it better to have packages defined in packages.config in the solution folder rather than in one of the projects?
If projects use different NuGet packages, the packages.config in the solution folder will enumerate all of them. Is it fine?
If I remove the packages.config from each project and add a packages.config in the solution folder, will Visual Studio update that file everytime I update/add/remove packages?
Would this be a recommended approach?
Note that I have tried this and it seems to be fine except for point 3 where Visual Studio does not seems to recognize the packages I have installed. Apart from that point, this question is very best-practice related.
OK this is what I do and you can do too.
In your solution, create a project say MyProject.Nugets. Install all Nugets into this project. Output of this project will be a folder inside development folder. All your other project will refer dlls from this folder and no other project will have packages.config.
Benefits:
All projects will be referring same version of a package.
Centralized controlling project for Nugets instead of multiple packages.config.
You want the packages.config per each project in the solution so you can track what packages are needed for the solution. U can manage the packages per project or per solution. This allows you to have different versions of the same package in different projects.
If you are not familiar with package manager https://learn.microsoft.com/en-us/nuget/tools/package-manager-ui. Other than that just set up your package restore.
The NuGet team deprecated solution level packages in NuGet 3.0 and they would not plan to support them going forward. There is a discussion about bringing back solution level packages in a way that is compatible with Visual Studio 2013 for a future version of NuGet.
This deprecation was not published visibly and detailed reasons. From my personal experience, the reason for this deprecation should be the problem of different projects referring to different versions of the same package which isn't possible with solution-level packages.
I know people normally add a dll file into the reference of Visual Studio very easily as follow:
1) Right Click on Reference
2) Choose Add Reference
3) Browse and choose dll file
However, with this approach, VS seems to store the absolute path, pointing to my dll file, rather than copy dll file into VS's project memory.
What if I remove the dll file from the hard driver? or what if I want to deploy the project on another computer?
Sorry, I am quite new to .Net
As described in your question, this is the way you reference a class library or any other DLL-like reference.
Once compiled, your project copies its dependencies into its bin folder where you can find the referenced DLLs.
If you can't find the referenced DLL, set its Copy Local property to true.
Another way around is to set your Reference Paths. This will force, on compile-time, your project to update itself with DLLs from the specified reference paths.
The best practice was to create a Shared folder where all referenced libraries were in, so that you could write your reference paths once and for all per project.
Technologies being so great and vast on improvements, there's now NuGet Package Manager.
What is NuGet?
A collection of tools to automate the process of downloading, installing, upgrading, configuring, and removing packages from a VS Project.
How to use NuGet?
You may install it from within Visual Studio if it is not already installed, through the Extension Manager.
Otherwise, please visit the NuGet CodePlex Home Page.
Here's how Finding and Installing a NuGet Package Using the Package Manager Console has never been easier! =)
So when you open up an existing project, NuGet manages to get all the dependencies for you without any more effort from you. This should solve your concerns.
I'm having a particularly difficult refactoring session involving a C# solution with multiple projects in Visual Studio 2012. I needed to pull out a bunch of code into their own assemblies so that code could be shared across several projects, all in the same solution. However, no matter what I try, I get warnings for the projects that reference the new shared projects that "All projects referencing {shared project name} must install nuget package Microsoft.Bcl.Build".
I have been over the dependent projects and the shared projects with a fine-tooth comb, verifying in detail that they all use the same version and exact same DLL for the Microsoft.Bcl version 1.0.1.19 and Microsoft.Bcl.Async version 1.0.16 packages:
System.Runtime
System.Threading.Tasks
Microsoft.Threading.Task
Microsoft.Threading.Tasks.Extensions
Microsoft.Threading.Tasks.Extensions.Phone
The DLL paths are all resolved and identical. The XAP file does build but I still get that warning telling me that Microsoft.Bcl.Build is not referenced in the dependent projects, despite the fact that I can see that it is.
If I try instead to uninstall and then reinstall those two packages using NuGet for each project involved, I get references with empty paths and the warning icon for the 5 DLL references involved. For some reason NuGet adds the references but can't find the DLLs. Also, if I do this, I find myself with the problem frequently of having projects where I get the "Can't add reference" error when trying to add a reference. Then I have close and re-open the solution, and that leads to a "project failed to load" error. So I have to edit the project file manually, remove the faulty package import statements, and reload the project.
How can I fix this problem and what is the general technique for avoiding this headache in the future? Letting NuGet manage missing packages didn't help at al.
In case anyone else comes across this and #Swell's solution made you go "wtf":
I recently went through an older MVC project and updated it (updated razor, asp, http, etc. nuget packages). The project, independent of itself, built fine, but when i went to publish it failed with the OP's errors.
It turns out it's because I didn't update the *.Tests project associated with it (should have figured, though not sure why Tests is that closely tied to the project). So, to fix:
Right-click the Solution and manage nuget packages.
Go through all the packages that were updated in the web project and apply them to the other projects as well (each "Update" will display a tree with the applicable projects, I was fine just OKAY-clicking through).
Rebuild.
You should now be good and it shouldn't bark at you. Hope that helps others.
I just came throught the same issue and a bug is opened here: http://nuget.codeplex.com/workitem/3268
What I've done is the following, I added to the solution level the package Microsoft.Bcl.Build
In my dev env if you don't have the package loaded, just right click the solution and select manage nuget packages, you see a yellow bar with a restore button, just click it and you will be fine.
In my build script before compiling the project I run this command:
.\myproject\.nuget\NuGet.exe install .\myproject\.nuget\packages.config -OutputDirectory .\myproject\packages
This will restore solution level packages and you will be fine.
This should be fixed by the end of this summer in version 2.7 according to the issue report