Improvement: Handle platform specific assemblies (x86, x64 etc) with msbuild conditionals #8573
Comments
|
It is possible to build a package like this, that supports Packages.Config and PackageReference scenarios. Your SIPSorceryMedia.1.0.0.nupkg would have a structure like this: ref\netstandard2.0\SIPSorceryMedia.dll the targets file would be created to handle packages.config scenarios. Related docs: Please let us (@rrelyea and @zivkan) know if you have any problems. |
rrelyea
added
the
Resolution:Question
|
Thanks a lot for the pointers.
That's the problem. I cannot find a way to make assembly reference in the targets/props files override the assembly reference that gets set when the nuget package is installed. For example installing the nuget package in a consuming project results in the reference being added as below and the only way I have found to override it is the suggestion in my first post. I tried the creating the package as per the architecture specific folders reference but that does not seem to do anything useful. My The sole problem I'm having is the consuming project compiling against the reference assembly that does not match the build platform. I've not been able to find a way to get the build to use the correct reference assembly at compile time if it does not match the original reference added by the nuget install. (in the diagram below lib\net47\SIPSorceryMedia.dll is compiled as x86)
Update: This is the build warning: |
|
At a glance, your attempts in your first post about putting a condition on It's unclear to me if the project you're testing with uses To work correctly in PR projects, your compile-time assembly should be in |
Do you mean why the condition for the reference in the
The source assembly is Managed C++. I guess it would be possible to front it with a reference C# assembly but that seems like a lot of overhead. I spotted this adding-a-packagereference-condition to do with setting a framework condition on a nuget reference. The equivalent condition for a platform seems to be what's missing. |
A screenshot of the binlog analysis is shown below. The only thing I spotted that looked relevant was the
|
I just meant that MSBuild supports skipping over XML elements when the condition evaluates to false. So the concept of having two Perhaps the issue is that
Then only option is to include a MSBuild props and/or targets file in your package, and do whatever is needed in there. edit: I forgot to mention that you should not have any dlls in
For C++ projects, yes, it's the only option. For C#/VB.NET/F# SDK style projects, only PackageReference works, packages.config is not an option. For C#/VB.NET (and possibly F#) projects using non-SDK style projects, it's possible to choose. See the NuGet-General options in Tools-Options for the default and option to prompt on first package install. |
|
@zivkan thanks to all your suggestions I was finally able to construct my nuget package so consuming projects build without warnings and get the correct native dll's copied to the output directory. The main thing was not to put anything in the nuget package's lib directory. I've pasted the
|
Lots of us are having issues using nuget to package platform specific assemblies (#8435, #1221 etc). The crux of the problem is that while the platform specific artifacts can be packaged with nuget if the assembly reference(s) is platform specific there is no clean way to set it in the consuming project file.
To illustrate the problem my partial nuspec is:
The subsequent reference that ends up in a consuming project files is:
I have found no way to be able to override the hint path in that reference with the use of platform specific overrides in a
.propsor.targetsfile. For example if msbuild accepted an override on the hint path of the original reference it would be possible to use the exampleSIPSorceryMedia.propsfile shown below. Unfortunately it doesn't work.But what does work is if the reference inserted into the project file has a platform specific condition:
Suggested Improvement
The suggestion is if nuspec file references could be specified as:
Then the references could be added to the consuming project as shown below and which builds correctly when the msbuild platform is specified:
The text was updated successfully, but these errors were encountered: