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
Related
Context
I have a Managed C++/CLR library which is built using CMake 3.17, and packaged into a NuGet package using CPack. The resulting nupkg file cannot be imported into a C# project, as the Package Manager issues the following error: "[snip] the package does not contain any assembly references or content files that are compatible with [.NETFramework,Version=v4.5.2]". However, adding a reference to either the project when added to the solution, or the corresponding library file generated by the build, works as intended.
C++/CLR Details
The code itself is very basic and produces a valid library which can be referenced from another project, when manually adding a reference via Visual Studio 2017 -> Add Reference (either the project or the corresponding library can be added this way and it works all the same).
The code consists of the class itself, and AssemblyInfo.cpp provides attributes which describe the metadata and version information only. The dependencies include only System, System::Runtime::InteropServices, and a raft of pre-built native libraries.
I have not added a .nuspec file, nor a nuget.config file, the latter which I believe is generated by the CPack NuGet generator when the package is built.
CMake / CPack Details
CPack NuGet support is relatively new, and I have been unsuccessful in finding a working example, but I have managed to successfully generate a nupkg file. Firstly CMake is instructed to build a Managed C++ library with the included source files, and the following properties set on the corresponding target ManagedLibrary:
set_target_properties (ManagedLibrary PROPERTIES DOTNET_TARGET_FRAMEWORK_VERSION "v4.5.2")
set_target_properties (ManagedLibrary PROPERTIES COMMON_LANGUAGE_RUNTIME "")
The documentation states that this will generate CLR/Mixed code and works as advertised, so I am able to successfully build against the target framework. The next step was to install the library in what I believe is the correct location:
install (TARGET ManagedLibrary DESTINATION . COMPONENT MixedCLR)
And supporting (native C++) libraries are installed similarly:
install (FILES [various..] DESTINATION . COMPONENT MixedCLR)
I also set CPACK_GENERATOR to 'NuGet', and then run the PACKAGE step from the CLI using cmake --build . --target PACKAGE which successfully produces the nupkg file.
Question
How does NuGet know what libraries to add a reference to?
Is a nuspec file required? If so, what must minimally be included in it, and how do I include it in the target CMakeLists.txt?
Is it acceptable to put the managed library, along with supporting native libraries, in the root of the package? If not, where should they go?
Are any other files generally included in a nupkg file?
Finally, if anyone knows anything about packaging and multi-targeting in C++/CLR to support different framework versions / architectures / build configurations, any notes on that would be highly appreciated.
How does NuGet know what libraries to add a reference to?
Primarily NuGet infers the libraries to reference from the package structure. Managed assemblies must be put in a directory which is libs/<TFWM> where TFWM is the Target Framework Moniker (eg: .NET Framework 4.5.2 => net452).
Is a nuspec file required? If so, what must minimally be included in it, and how do I include it in the target CMakeLists.txt?
The nuspec file is automatically generated by CPack at package generation time. The generated file is saved to the output directory, and will preserve the directory structure specified by the install command.
Is it acceptable to put the managed library, along with supporting native libraries, in the root of the package? If not, where should
they go?
As already discussed, the managed libraries go in libs/blah. Native libraries, on the other hand, go in runtimes/<RID>/native where RID is the Runtime ID. In my case I wanted to target Windows 64-bit, so the Runtime ID is win-x64.
Are any other files generally included in a nupkg file?
I bundle the PDB for convenience, but I didn't need to specify any other files or properties.
Finally, if anyone knows anything about packaging and multi-targeting
in C++/CLR to support different framework versions / architectures /
build configurations, any notes on that would be highly appreciated.
If targeting multiple framework versions it's simply a case of creating and installing multiple targets into the respective folders, there's nothing more complex to deal with.
Finally, my finished package structure looks like the following:
libs/
net452/
ManagedLib.dll
ManagedLib.pdb
runtimes/
win-x64/
native/
NativeLib1.dll
NativeLib2.dll
...
I hope this helps someone in the future.
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 program written in C# and there is a TwitchLib.dll that provides some stuff about Twitch.tv API I guess and I want to update the .dll since there were some changes in API. How can I get .dll from a nuget package (TwitchLib).
I've tried going to /.nuget/packages/twitchlib/3.0.1/ and there is no TwitchLib.dll while for example in /.nuget/packages/twitchlib.client/3.0.3/ there is. I need .dll that is for whole TwitchLib library, not only specific parts of library.
Just build the class library by clicking the right click on solution explorer and you will see the NameOfLibrary.dll file in packages folder of your project directory.
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!
I'm getting my knickers in a twist with 'project' versus 'package' (ie Nuget package) references in asp.net 5.0. I'd really like for someone to explain a bit more fully the way references are pulled in in asp.net 5.0. How does a 'dnu restore' determine if something is a project reference rather than a package reference?
I had thought that a reference would be pulled in as a project if the projects were in the same directory, but this is clearly not the whole story. It does appear that you can have a deeper directory nesting and still pick up the project reference.
Here is an outline of my common project structure:
I've got a set of projects, some of which reference one another. There are libraries called TextHelpers and MathHelpers and a project called MainProject. The libraries live in a folder called Libraries, and the MainProject lives in a folder called Tools. This separation is necessary as Libraries and Tools belong to different Git repos:
Root/Libraries/TextHelpers.Project1 - version 1.0.0-*
Root/Libraries/TextHelpers.Project2 - version 1.0.0-*
Root/Libraries/MathHelpers.Project1 - version 1.0.0-*
Root/Libraries/MathHelpers.Project2 - version 1.0.0-*
Root/Tools/MainProject - version 1.0.0-*
Usually MainProject references the libraries as Nuget packages from a private Nuget repository (just a folder on the file system) which serves the libraries.
While I'm building MainProject, however, sometimes I need to make a change to one of the library projects, or sometimes I'd like to step into the files without using a Nuget symbol server. For this reason, I'd like to switch to referencing the (live) projects rather than from the (static) Nuget packages. How would I do this?
I've discovered this much so far: if I have a global.json file, a 'dnu restore' creates a project.lock.json with 'project' rather than 'package' references. Is this the whole story?
dnu and dnx look in the following folders:
The folder where the current project is (that means the parent folder of the folder containing the project.json of the current project). E.g. if you have repo/src/project1/project.json it will look in repo/src
Any other folder included in global.json
Then the algorithm is really naive: if it finds a folder with the name matching the package in any the folders mentioned above it will assume those are the sources for that package.
For example, if you have
src/P1/project.json
src/System.Collections/project.json
and in src/P1/project.json you have a reference to System.Collections, it will use src/System.Collection instead of the NuGet package System.Collections. Projects take precedence over packages.
Caveats:
Since the algoritm looks in the current folder and everything in global.json you might be able to reference some projects from one folder but not another. If in my previous example you'd add a test/T1/project.json project but src is not in global.json then the projects in src will reference System.Collections the project while T1 will reference the package (installed in the global packages folder).
There's no verification to see if the project reference is actually that package. If the name matches, it's a match. So an empty project could replace any package.
If you have multiple project with the same name you can get in trouble.
Hope this helps and answers your question.
Side note: with dotnet (the tool replacing dnx) you can specify for every reference if you want the project or the package to have higher priority.