I have a solution AddLog which has only one project AddLogClient of type shared project. I created it by right clicking on solution name->Add->Shared Project.
I want to use this shared project in other solutions. When I go to another solution MyApplication and want to add a reference to AddLogClient, I can't see it in the list of shared projects, because it is not located in the same solution. When I try to browse for it, it expects a file in .exe, .dll, .tlb, .olb, .olx or .winmd format. Adding .dll file (from bin folder from AddLogClient) would not be acceptable because every developer has different repository checkout location and we can't use relative paths.
How can I reference shared project from other solutions? Both solutions are under SVN.
The standard way of doing so, as #Sokopa suggested is through NuGet. For dev purposes, if you do not want to publish packages to Nuget servers, you can check the Generate Nuget Package on Build option and upon build it will create a nuget package in your build folder.
check this guide from microsoft docs
Related
I'm trying to get my PCL library that uses Nuget packages to copy the dlls it requires to its output directory. For example, I use the Portable Licensing nuget, but it unfortunately does not copy its dlls to the output folder despite having tried multiple solutions/recommendations found on the web.
I've tried a few things based on this page: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Manually setting IncludeAssets to all for each nuget required, locking the dependencies, using the Target build arguments found in another post, etc. Nothing seems to work.
A couple things to note:
I cannot set anything in terms of the nuget refrence. Pic of what my properties window looks like: https://i.imgur.com/cvTQFM6.png
My project does not have a packages.json file. I created a blank project, added the nugets I needed, and copy-pasted the packages.json file from there to my main project, but it still didn't work. The blank project, when compiled, does have the dlls copied to its output directory.
This is a PCL project.
Can I use Nugets properly with PCL projects? Is there some setting I'm overlooking? Any help would be greatly appreciated!
There is one shared solution which uses packages (obtained via nuget, for example Elmah). This solution generates DLLs.
I have several solutions which want to use those dlls. I've added them via "Add reference".
This works when I have my nuget packages installed on every solution, but when i uninstall it from the descendant - it can't find it. I understand why (it does not copy folder with packages from sharedSolution, only generated DLLs), but I wonder what is best practice in such situation?
If you prefer to manage the DLLs shared across multiple solutions manually, the steps would be:
After loading the NuGet package to one of your solutions, navigate to the package location and copy all the required DLLs (with the supporting XML files, if any) to a separate folder (e.g. Vendors\SharedPackage.Version1).
Uninstall the NuGet package.
Now using "Add reference", navigate to the location where you copied the SharedPackage in step 1 (Vendors\SharedPackage.Version1 folder) and add the required reference to all projects and solutions you want.
Note: If you go down this path, you'll have to manage all the SharedPackage updates manually: Get the updated package via NuGet, copy the package contents to a separate folder (Vendors\SharedPackage.Version2), uninstall the package, remove references to the old package from all your projects in all solutions, add references to the new version of the SharedPackage.
Alternatively, if you want to have your NuGet packages managed by the Visual Studio, this thread is the best source of information I could find on this topic. Vermis has done a great research work!
P.S. Imho, the manual solution is easier to implement but harder to maintain. The decision is up to you.
I have a smallish solution, with about under twenty projects. The solution used to also contain about six source projects written by a third party service provider, ACME. Now, finally, this other party is supplying us only with a handful of DLLs. I used to just included their source, one project per DLL, in the solution, and so I am looking for a neat way to include all these assemblies in the solution, so they can be referenced from the many projects that need them.
My immediately apparent options are:
Create an AcmeAssembly project, add all DLLs as project items set to copy to output.
Create an AcmeAssembly solution folder. Quicker and simpler than a 'binary-only' source project, but solution folders have the very, very large drawback of having no means of grouping the files without a solution file, i.e. outside of VS.
Create a NuGet package that includes all the required binaries. Then at least we also have a partly 'phycical' grouping in the packages folders. My problem here is I have never written a NuGet package, but I am not asking how to here. I am asking about three candidate solutions, and more will be welcome, and if NuGet wins, I get to learn to write a package.
I can't simply use the project's output bin\debug and bin\release folders. To me, these are strictly output folders, and nothing but other dependency assemblies should also be output there. Deleting the bin folder should have absolutely zero effect on a build, so that is certainly no place to store binaries.
The advantages of nuget over the other solutions are:
Support for versioning
Support is built in into Visual Studio and MSBuild
No 'magic folders' that all developers need to have on their machines
Create your Acme library folder (something like: C:\Source\Library\AcmeLibrary). Put all of your Acme dll's in that folder. Then create the Solution Folder in VS and add the existing items to it (don't add the folder, but the items in the C:\Source\Library\AcmeLibrary folder to the solution folder using "Add Existing Item..." menu selection).
I have a need to copy a .NET project / class library from one solution to another.
Does a copy/paste and subsequent inclusion of the project in the new solution suffice?
Or are there any caveats?
(like generating a new Project GUID etc...)
The main reason I ask is because the nuget packages are not restoring and being added to references at all after I copy and include the csproj.
I faced the same problem, and it was because in the new Solution the NuGet Packages folder was in a different location relative to the project. To get around it I took the following steps:
Copy the project into the directory you want it to be in
Edit the csproj file so that all references to the Packages folder are correct relative to the new location
Add the project to the solution and build - packages will be restored
I was creating ASP.NET MVC 5 web app and put it in the Team Foundation Server source code control (visualstudio.com). There is a folder named "packages" that contains all assembly I've got thru nugget. After a while, I need to create another app, and I use TFS to get latest version of my code from TFS. But all the references to the third parties assemblies that point to the folder "packages" seems to have some problem. The icons has yellow triangle with exclamation point for each assembly. How do I fix this problem?
That's because NuGet just creates the folder with referenced packages but it doesn't add it to your source control. Why don't you just add the folder NuGet created to your solution and that way it will become a part of your project in TFS?
That way your TFS server will have all the required packages and will be able to copy the packages to your new solution or if you try to open the solution on another computer.