Nuget package reference (WMPLib) not recognized in code - nuget

I try to add the WMPLib nuget package as a package reference to my project, but in the code the classes could not be found.
This is in my csproj file:
<PackageReference Include="WMPLib">
<Version>1.0.0</Version>
<IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
And in my cs file I have:
using WMPLib;
And this is the error:
error CS0246: The type or namespace name 'WMPLib' could not be found (are you missing a using directive or an assembly reference?)
Here I read that "the issue is due to the new NuGet format reference 'PackageReference' ... the folders and files aren't added".
Does someone know more about this? And is the solution using a package.config instead of a package reference?

Okay, I was able to reproduce your problem and also found some kind of workaround.
Problem
It seems to me that the original WMPLib NuGet package is somehow broken/not really compliant to nowadays NuGet's expectations. I think so because of the following two indicators:
Normally nuget.org shows all the compatible target frameworks of a package, but for WMPLib, it shows only .NET Framework (see here) - but which version? Compare it e. g. with Newtonsoft.Json.
When analyzing the package with either dotPeek or 7-Zip, I found the assemblies inside the lib folder. But usually, they are inside lib\<<TFM>>, e. g. lib\net48.
Workaround
I've extracted the two assemblies AxInterop.WMPLib.dll and Interop.WMPLib.dll using dotPeek and saved them in C:\temp\NewWMPLib\lib\net35.
Then I've created the following file C:\temp\NewWMPLib.nuspec:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>NewWMPLib</id>
<version>1.0.0</version>
<authors>me</authors>
<owners>me</owners>
<description>Lorem ipsum</description>
</metadata>
</package>
Finally I build a new NuGet package via nuget pack C:\temp\NewWMPLib.nuspec.
When consuming this package via NuGet, the following code now compiles:
using WMPLib;
namespace ConsoleApp4
{
internal class Program
{
static void Main(string[] args)
{
var windowsMediaPlayerClass = new WindowsMediaPlayerClass();
}
}
}
Disclaimer
I'm not a lawyer and I have no clue whether following my workaround is legally safe.

Related

How to properly define a NuGet package for an assembly where the dll file name is different from the assembly name?

I had to package a portable version of Newtonsoft.Json as an internal NuGet package under a different name (Newtonsoft.SL5.Json). The reason is that we are building into a shared bin directory and I do not want the Silverlight version to overwrite the full .NET version. (Yes, we still have Silverlight and yes the portable Json.Net version is not good enough for non Silverlight code we have)
The package file name is Newtonsoft.SL5.Json.8.0.1.19229.nupkg
Inside it there is Newtonsoft.SL5.Json.nuspec
Inside it there is lib\sl5\Newtonsoft.SL5.Json.dll
The nuspec file content is:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
<metadata>
<id>Newtonsoft.SL5.Json</id>
<version>8.0.1.19229</version>
<authors>Newtonsoft</authors>
<owners>Newtonsoft</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Json.NET Portable .NET 4.0</description>
<copyright>Copyright © James Newton-King 2008</copyright>
</metadata>
</package>
Now something I am doing wrong, because as a result, when adding the dependency in Visual Studio, the reference it produces is:
<Reference Include="Newtonsoft.SL5.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\..\packages\Newtonsoft.SL5.Json.8.0.1.19229\lib\sl5\Newtonsoft.SL5.Json.dll</HintPath>
<Private>True</Private>
</Reference>
And of course, there is no such assembly Newtonsoft.SL5.Json. It should be Newtonsoft.Json.
So, I am doing something wrong. How should I change the NuGet package so that it uses the correct assembly name, i.e. Newtonsoft.Json? Because even though I changed the file name, the assembly name is still the same.
while adding reference IDE takes .dll files that are included in the package (lib/{platform}/). If you rename those files added and packaged in nupkg file -> those should be added in element.

NuGet package adds incorrect hint path

During an automated build, my nuget package needs to be non framework dependent, however I keep finding that the nuget package getting added is incorrectly adding a HintPath.
Within my nuspec I've defined the files that are part of the package:
<files>
<file src="lib\xyz.dll" target="lib\xyz.dll" />
<file src="lib\xyz.xml" target="lib\xyz.xml" />
</files>
However whenever I add the package to my project/solution, it incorrectly adds a hint path specifying:
<Reference Include="xyz, Version=11.0.0.0, Culture=neutral, PublicKeyToken=4a3c0a4c668b48b4">
<HintPath>..\packages\xyz.11.0.0.0\xyz.dll</HintPath>
<Private>True</Private>
</Reference>
This is causing the automated build server to not find the assembly and fail to build. I can manually fix the hint path, but would rather not.
I took a look at this post (Failed to add NuGet package) but I don't find it relevant. This post (NuGet package install uses specific assembly version in csproj files) seemed to be referring to the same problem but with no answer. Anybody have any thoughts?
You can work around this by using a custom MSBuild task.
Instead of adding the assembly to the lib directory create an MSBuild .targets file named after the package id and put your xyz assembly next to it.
\build
\Net45
\MyPackage.targets
\xyz.dll
\xyz.xml
Then in the MSBuild .targets file add the reference exactly how you want it to be. Something like:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Reference Include="xyz">
<HintPath>$(MSBuildThisFileDirectory)\xyz.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
The above shows how to specify a hint path relative to the MSBuild .targets file. You said that you do want to use a hint path so you could remove that if xyz.dll can be resolved by MSBuild somehow, such as it being in the GAC.

nuget pack ignores package.config dependencies

I cannot get nuget pack X.csproj to recognize package dependencies in a project. Amazingly, when packaging, the diagnostic message “Found packages.config. Using packages listed as dependencies” is printed, but in the end the <dependencies/> tag in the .nuspec file inside the package is empty.
The packages.config for the project does indeed contain references:
<packages>
<package id="SmartAction.Logger" version="1.0.2.0" targetFramework="net40" />
<package id="SmartAction.Pervasive" version="1.0.1.0" targetFramework="net40" />
</packages>
To narrow the problem down, I removed my own parallel .nuspec file, and mostly all switches from the nuget pack command:
> nuget pack libToneDetection.csproj -prop Configuration=Release
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Attempting to build package from 'libToneDetection.csproj'.
Packing files from '[snip]\Core\ToneDetection\libToneDetection\bin\Release'.
Found packages.config. Using packages listed as dependencies
Successfully created package '[snip]\Core\ToneDetection\libToneDetection\SmartAction.Audio.ToneDetection.1.0.0.0.nupkg'.
NuGet Version: 3.3.0.212
The only difference I can spot with this project is that its name is different from package name (I am trying to maintain them in sync but this is older stuff I am repackaging).
I doubt I had ever seen this before. I am finding questions on SO from people trying to prevent references in packages.config from becoming dependencies of the package, but none from those trying, like me, to beat the reverse problem. Help!
Addendum. I copied the project out of the solution with other projects to a temporary directory and rebuilt the package from there. Now one of the two dependencies from packages.config was added to the package:
<dependencies>
<dependency id="SmartAction.Logger" version="1.0.2.0" />
</dependencies>
Thinking of the differences between the two, the SmartAction.Logger package depends on SmartAction.Pervasive. But the package I am compiling really uses both.
To me, either behavior looks incorrect. Am I hitting a nuget bug, or a cryptic complex feature?
Xref: Opened https://github.com/NuGet/Home/issues/1867

NuGet pack fails with "Unable to find '#(_OutputPathItem->'%(FullPath)..."

I'm attempting my first NuGet package, and I'm running into some trouble. I have a fairly simple project, and a very simple .nuspec file:
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<description>$description$</description>
</metadata>
</package>
When I run NuGet pack with this command line:
NuGet.exe pack mylibrary.csproj -Verbosity detailed -Properties Configuration=Debug
I get this error:
NuGet.CommandLineException: Unable to find '#(_OutputPathItem->'%(FullPath)mylibrary.dll')'. Make sure the project has been built.
at NuGet.Commands.ProjectFactory.BuildProject()
at NuGet.Commands.ProjectFactory.CreateBuilder(String basePath)
at NuGet.Commands.PackCommand.BuildFromProjectFile(String path)
at NuGet.Commands.PackCommand.BuildPackage(String path)
at NuGet.Commands.PackCommand.ExecuteCommand()
at NuGet.Commands.Command.Execute()
at NuGet.Program.Main(String[] args)
The output files are definitely in the bin\Debug folder, but NuGet is apparently not finding them.
This apparently only happens when the .csproj file's ToolsVersion is set to 3.5 or lower. Setting ToolsVersion to 4.0 resolves the problem.
It seems that MSBuild 3.5 returns the unexpanded property value when calling _project.GetPropertyValue("TargetPath") (ProjectFactory.cs ~296), where MSBuild 4.0 returns the expanded property value.
We had the same problem. adding
-Prop Platform=AnyCPU
to the command line made it work for us.
This apparently only happens when the .csproj file's ToolsVersion is set to 3.5 or lower. Setting ToolsVersion to 4.0 resolves the problem.
I have created an issue for the NuGet project team here: https://nuget.codeplex.com/workitem/4012
This could also have the same error if the .NET Framework version is set to 4.0 for the assembly.

An item with the same key has already been added nuget error

I am currently creating a nuget package with a nuspec file but getting the following error:
An item with the same key has already been added.
My command I am using is:
nuget pack "MyProject.csproj" -o "..\Packages"
This is my nuspec file:
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
<language>$language$</language>
</metadata>
<files>
<file src="bin\MyLibrary*.dll" target="lib\net45" />
</files>
</package>
The nuspec file I am using is also used when packaging other packages withing the same library. Could this be the reason why the above error is occurring? Any ideas?
It might be that you are adding files in nuspec that are also getting added when you call pack on the .csproj (files/dlls referenced by the csproj). If so you can remove the file references from the nuspec file and give it a try.
how does your nuspec file look like?
I created it with the following steps
1. create the Mylibrary project
2. let me add a dependency, I installed ninject package to the project
3. build
4. nuget spec mylibrary.csproj
5. nuspec file generated, I didn't add any file or dependency manually to the file
6. nuget pack mylibrary.csproj
7. nuget pack would automatically add ninject as a dependency and also add mylibrary.dll into the correct folder
8. http://npe.codeplex.com/ is a nice tool to open the nupkg file and see what got generated inside the package.
I had this error trying to use the package visualizer and it ended up that my packages.config had the same package name in it more than once with different versions.