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!
Related
I have a solution with an application project (ASP.NET Core) and multiple library projects. I want to separate some of the library projects into a separate solution and turn them into NuGet packages.
With the libraries in the same solution I could of course simply edit something in a library, run the application and see how it works (and debug, if necessary).
However, when I turn the libraries into a NuGet package, the application references the packages from our private NuGet feed instead of the project file.
My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).
DNT (Dot Net Tools) does this. You can specify which packages to switch and where they are.
See the 'switch-to-packages' and 'switch-to-projects' command line switches.
Its a bit fiddley as (when I last tried) you had to create a config file that holds the mapping, and it seems to be easy to break the switching. But its something.
https://github.com/RicoSuter/DNT
I've not tried it, but maybe you can use it to switch to packages on a commit for the build server to work correctly? (Or to ensure the references are correct in source control?)
If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.
Once you install the nuget, no matter how many changes you make, it’s useless. The nuget installed at this time is the version you made before any changes. No matter how you change it, it is the previous version. The version stays at that timestamp, unless you repackage the project. Generate nupkg and update the nuget version.
So nuget is not a good choice for your situation, you should use ProjectReference.
Directly use the ProjectReference to reference two source projects, build at the same time, and get the changed parts at the same time.
ProjectReference could cross two different solutions.
Add this on the main project:
<ItemGroup>
<!--add any nuget project'csproj file like this to debug its source code-->
<ProjectReference Include="..\xxx\xxx.csproj">
</ProjectReference>
</ItemGroup>
If the proejct is out of the solution, you could directly use the full path of the nuget project's csproj to connect it.
I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.
This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.
Disclaimer, I am creating the Nuget in question.
I am currently in the process of creating a Nuget package for Xamarin Forms, which has been going great. Here is the repo. I have gotten it fully working no issues.
I have also been testing it by including it as a project reference in another, closed source, repo. And this has also been working perfectly fine.
However, I decided to switch from using the project reference to using the actual Nuget, since I was no longer tinkering with the code on the fly to make it work correctly, and I have hit a wall.
The moment I include the package, I am given upward of 5000 errors, which are either
(/Users/UserHere/Projects/PopupsError/PopupsError.Android/CSC: Error CS1703: Multiple assemblies with equivalent identity have been imported: /Users/UserHere/.nuget/packages/awaitablepopups/0.2.5/lib/netstandard2.0/System.Xml.XmlSerializer.dll' and /Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.XmlSerializer.dll. Remove one of the duplicate references. (CS1703) (PopupsError.Android))
or
(/Users/UserHere/Projects/PopupsError/PopupsError.Android/Resources/Resource.designer.cs(36,36): Error CS0731: The type forwarder for type 'System.Attribute' in assembly 'netstandard' causes a cycle (CS0731) (PopupsError.Android))
And a multitude of others, I have a completely fresh repo with just the Nuget added here
The bit that is most confusing to me, is that the same exact project works as a project reference, but if I make it a Nuget and add it in, then it throws the error seen above.
I am under the impression, that its some small option I could add, but after some research, I am unable to figure out what small option I should tick. Any help would be greatly appreciated
This is sometimes headache.
For local projects migrating from packages.config to PackageReference
You have to go and delete duplicate nuget from physical disk.
Delete this folder /Users/UserHere/.nuget/packages/awaitablepopups/0.2.5/lib/netstandard2.0
Since you mentioned you moved from packages.config to PackageReference within csproj file, you have to be also careful that csproj still doesnt have old style imports , you can fix this by comparing your csproj file with newly created project csproj file as reference.
Delete and remove "package.config" and 'app.config` reference from csproj file as well.
Update
For NuGet
Check .nuspec file and remove reduntant imports
Clean the project , delete bin obj folders manually as well.
Remove NuGet.Build.Packaging , its not required. Its adding all of those reduntant assemblies.
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
I have a nuget package that contains Resx files, for instance MyResources.resx and MyResources.fr.resx.
I have a UWP app which references this nuget package. In my Nuspec file I configured the resx dlls for each language to be copied to the project that references the nuget package. At the end when I compile the project that references this pacakge I can find one folder called "fr" which contains a dll for the resources.
Now, this nuget package is a library that contains a class that uses the resources, for instance I have a property that returns MyResources.MyLabel;
If I add the project from which I create the nuget package directly onto my app solution and then reference the project directly, when I run my app and I change my region and language I can see the label being translated.
The error comes when I reference the nuget package instead of the project directly then whenever I get the label I always get it in English. It does not recognize the culture or maybe the file containing the labels is not found.
Any suggestions? I havent been able to find the fix for this or any discussion related to this scenario. I also set my resx files to be public so I can actually go into my app and call the resource directly but it still only in english no matter what.
Any help is appreciated.
Thanks
I'm trying to figure out what the best way to handle this scenario is.
Let's say I have a library that's referenced by multiple different non-related solutions, let's call it WebServiceInterface.dll. This library has a dependency on JSON.NET.
Before NuGet
The JSON.NET binary was referenced via a SVN external in the WebServiceInterface project. Other solutions which had a dependency on WebServiceInterface referenced the project (also as an SVN external) and as a result pulled both the project, and it's dependencies.
With NuGet
I haven't figured out how to force the JSON.NET reference to be stored under the WebServiceInterface project (as opposed to the RandomSolution\packages location). I found reference # nu-get to project-level and solution-level pacakges, but I can't seem to find out how to specify this when I add a dependency via nu-get.
The goal here is that when someone checks out WebServiceInterface and adds it to a new solution that it builds (instead of having broken references to JSON.NET which point to the packages directory under whatever the last solution was that checked in).
When I went to find out if Chris B had created a NuGet issue for this, I couldn't find one. EDIT: He did, see his comment below. But I did find a semi-documented feature of NuGet that I used to solve this problem: Allow specifying the folder where packages are installed
Let me break this question into 2 issues:
getting NuGet to allow for multiple solutions to use the same packages location
getting the NuGet packages to automagically fetch from source control when you include a project that has NuGet packages
Problem 1:
By default NuGet stores packages in a packages folder in the solution's folder. To change that location, create a nuget.config file in the solution's root folder with the following contents:
<settings>
<repositoryPath>..\..\..\Utilities\Library\nuget.packages</repositoryPath>
</settings>
<repositoryPath> is relative to your solution; so obviously make it whatever you want. Make each solution have it's own relative path to the same packages folder.
As far as NuGet's flow, from that point, the paths in repositories.config are relative to the folder containing repositories.config, not the solution, so now all projects/packages are managed independent of the solution location.
This allows multiple solutions to use the same packages in source control, and if those solutions use the same projects (that use NuGet packages), those solutions/projects will all be kept in sync no matter which solution updates the package.
Problem 1 completely solved.
Problem 2:
Let me address this from 2 perspectives. This applies to Visual Studio and TFS -- I'll leave SVN for someone else to address.
First: if you have no source code on your drive and do a get of a solution (not a project), I prefer to make it so that you get everything that solution needs to build. There shouldn't be any missing references to go manually grab. That much we can do by adding the package files as solution items. Yes, in each solution. A bit of work, yes, but when it's done the package files will fetch/update from source control automagically.
Second: In a new solution, when you include an existing source control project that has NuGet packages, you have to manually fetch the packages from source control and add them as solution items. At least anyone else getting your solution in the future will automagically get everything they need to successfully build. At least with VS/TFS, this is just the way it is, AFAIK. If projB depends on projA, and you add projB to a new solution, VS/TFS won't automatically grab projA from TFS. You have to do that manually. So then the same goes for dll references (like NuGet packages).
Summary of my solution:
Only one copy of packages in source control for all solutions
Any solution can update packages and all the other solutions will be kept in sync*
* Once one solution updates packages to new paths or file names, they will appear as missing references to the other solutions and you'll have to manually clean that up. But at least you know right where the packages are in source control "(as opposed to the RandomSolution\packages location)."
The packages are always stored at the solution level, so if you install a package into multiple projects, they came from the same place. I don't believe you can configure it so that each project has its own packages folder.
I'm not sure there's a nice way to do what you're trying. You could maybe have a build step on the project that fetches the package, but I don't know how well that will suit you.
I'd recommend posting in the NuGet Issue Tracker to get a discussion going. The people working on it seem pretty active, so it might be something they can add support for in a future version :-)