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.
Related
Using: .net core mvc c#
I have a solution which has a .net mvc core web app & one class library. There is a shared project (class library) that I want to this solution
which is a part of different project (different solution as well).
All of these projects are stored in our local GIT repository.
If I add the external project as project dependency in my existing project then there would be 2 copies of the external project that we have to
maintain. If some developer updates external project how does the change propogates to other projects using it.
And there could be that some developer updates the external project when under its local solution which we want to prevent. Since all are in GIT
is it possible somehow to make dependency related so that any change in external is known to others.
So basically how can we prevent anyone to make local updates to the external project but also make sure any updates to external project are available to
any other project using them.
There are several approaches that you can use to achieve this.
Quick: Reference project in two solutions
The quickest is to reference the shared project from both solutions. This way, you can use it in both projects and the changes are propagated to the other solution because you are basically working on the same files. However, a huge drawback of this approach is that if you make changes in solution A that are not compatible with solution B (e.g. removing a method that is used in solution B), you will only find out when working on solution B.
Easy: Single solution
To fix this, you could merge the solutions into a single one that contains the shared proect and also the other projects from solutions A & B. This way, you still get the convenience of project references in a solution. In addition, you are notified about breaking changes immediately if you build the complete solution. If this approach is viable for you in terms of solution size and team structure, I'd favor this approach. As you already share a single Git repository, I think this approach is well worth considering.
Nuget Package
If you want to keep the solutions strictly separated, you'd need to follow a more complex procedure. You could for instance move the shared project into a solution of its own and create a Nuget package with a clear build and versioning strategy. You can host the Nuget package on a package feed (e.g. on Visual Studio Team Services). Solutions A and B can then reference the Nuget package from the feed and also update it if a new version becomes available.
Here the official documentation to create nuget package with nuspec or csproj
Create .NET Standard 2.0 packages with Visual Studio 2017 [CSPROJ]
Creating NuGet packages [NUSPEC]
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.
I am a dinosaur developer, so NuGet is relatively new to me, I am used to manage third parties open source libraries having a single project with the code or the binaries, that I will keep updated when necessary and this project publishes the dll(s) on a common folder from where I reference the libraries in all my projects. This makes easy to maintain the third party libraries and in my projects I just need to rebuild when I update the library and all goes OK. Now many open source projects publish their libraries on NuGet and it is easy to reference them in the projects, but I dread the fact that I have to download a copy of the library for each project in which I use it, this, in my opinion is something that can lead to chaos. Especially if I have 2 projects that build dlls that end up using 2 different versions of the same packages and are used both in an application with problems and conflicts. So my question to those who use NuGet from a longer time is:
Can I proceed with NuGet packages as with other libraries and create a project that references them, use it to publish the dlls in a single folder and then reference the dlls of the packages from my dlls and applications on the published folder.
I hope I've been clear. Thanks for any thoughts you can share on this topic
Sabrina
Having all your 3rd party libraries for all your projects in a single folder can lead to dll versions hell. If you update a single dll which contains breaking changes and which is referenced by other projects, then you will have fix/rebuild all projects that references it.
To resolve the issue with downloading the same packages for every project you can create a local repository and configure Visual Studio to use your local repository. So if your local repository contains a single version of log4net, you'll be able to use only that specific version. Even more you can configure repository to use a shared folder, in this case all developers and even your build server will be able to use that repository.
There are a lot advantages of using NuGet, such as saving a lot of space on your hard disks and others. For example I created NuGet packages for our internal framework, so all our projects just reference those packages, rather than each project has its own version in its bin folder.
I am building a new project in ASP.NET 5.
In my solution I have added a new Class Library (Package) project.
I right click on this project and choose for Manage Nuget packages to install PetaPoco.Core.
When I install everything seems fine except that the PetaPoco.cs file is not in my project.
In my references I se the PetaPoco version 5.1.171 installed.
Is this something different then a normal class library and do I need to use something else in order to use the installed PetaPoco class or is it a problem during the installation?
I have removed and reinstalled this but still the same.
Someone that can help me out?
/Michael
It looks like the PetaPoco.Core package isn't setup to be used in portable class libraries (PCLs).
Including content files in PCLs like the Models folder that PetaPoco.Core creates requires a different NuGet setup than a regular project. Documentation on this can be found on NuGet. I downloaded their package directly and can confirm that it is not setup in the way the linked resource describes.
It may be that the project requires features that are not available yet cross-platform, or they simply haven't had time to make changes to support PCLs, or some other reason that I am not aware of.
NuGet packages are usually installed as DLLs in the bin folder of your project, with the needed references also added automatically to the project. They usually don't include source files. You may find sources - if available - on the package/project website.
Visual Studio IntelliSense will pick up the DLLs and show what it can about the classes and methods inside, including comments and method signatures.
See here for a tutorial, including how to build your own NuGet packages.
EDIT: PetaPoco is the exception that does add a .cs file... see comment below.
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.