I installed a Nuget on top of an application. The Nuget had a dependency to a newer version of a 3rd party dll than the base application, and now the base application cannot run because of this. How to take care of that? Is this a sign that either the Nuget or the base application violates good principles?
Afaiu the base application requires an exact version of the 3rd party dll (and the Nuget requires a later version).
Is the only way to recompile the base application with updated refs - or recompile the Nuget with ref to the older dll version?
A possible workaround could be to install the Nuget withouth automatically installing the newer version of the 3rd party dll, but I don't know how to do that.
It's kludgey, but I would install the older version of the library that the base application requires to the GAC. This isn't ideal, and will have to be accounted for in your installation scenario, but the GAC does allow multiple versions of the same library to be referenced.
Related
I have a .NET Standard class library project. I want the library to be available to the broadest array of consuming applications, so following Microsoft's advice here, I am targeting .NET Standard 1.3 in my project properties.
However, there is also a NuGet package called NetStandard.Library. And somewhere along the line, my project got a reference to this as well. What's more, it's a different version (1.6). I'm confused. Is this okay?
What is the relationship between these?
And somewhere along the line, my project got a reference to this as
well. What's more, it's a different version (1.6). I'm confused. Is
this okay? What is the relationship between these?
I think you should not worry too much about that.
1.6.1 is just the version of NetStandard.Library nuget package and it has nothing to do with the version of the target platform, and they don't interfere with each other.
The NetStandard.Library nuget package just service the related net standard project and provide any libs and apis to develop,build, debug the current project.
Besdies, NetStandard.Library 1.6.1 service net standard 1.x project while NetStandard.Library 2.0.3 services net standard 2.x projects.
So when you finishing developing it and pack your net standard 1.3 lib project as nuget package and then use it in target platform, actually, NetStandard.Library nuget package already finish its job and it is irrelevant in this step.
When you use such net standard project into other target platform projects, you only need to consider that whether the net standard version and the target platform version are within the scope of support as your linked document describes.
--------------Update 1-------------
Actually, sure.1.6.1 version is just only the nuget package version. NetStandard.Library 1.6.1 nuget package defines one or more standard.net version libraries.
And as far as I know, 1.6.1 version supports net standard 1.0~1.6 class library projects and the nuget package services for those net standard version.
And then it will direct the current project to the corresponding target platform projects.
Hope it could help you.
This must be a bug of the NuGet Package Manager I'm using (version 4.6.0). I used the option DependencyVersion highest but it always picks the lowest version for dependencies.
Like this (I'm trying to install Serilog.AspNetCore with dependencies of 2.2.0 - the latest but 2.0.0 is always picked).
install-package Serilog.AspNetCore -DependencyVersion highest
One dependency it picks is Microsoft.AspNetCore.Http.Abstractions 2.0.0 but I expected it to pick Microsoft.AspNetCore.Http.Abstractions 2.2.0.
It's important because in my project the version 2.2.0 is required, Serilog should adapt that requirement by installing with that correct version of dependencies. But here I could not do anything to help it understand what I want.
Also the Install and Update options are not shown in the UI of NuGet Package Manager (the DependencyVersion could be selected there as well when using UI to install packages). So this appears to be some bug at least in the specific version of Nuget package manager I'm using.
What could I do to solve this issue? Can I try fixing the installed nuget manager (there is not any update in the Updates window). Thanks!
UPDATE
I've just tried a traditional .NET project, it works. But the problem raised when my projects target .NET Core (ASP.NET Core)? Looks like it does not support that feature for .NET Core projects?
The DependencyVersion switch is something used to control the behavior when NuGet looks for patch versions. It seems to be introduced after NuGet 2.8, but one point we should know is this option only supports packages.config format.
There are two package management formats:Projects.config and PackageReference.
1.For traditional .net project:It can use Packages.config or PackageReference to manage its nuget packages.But by default it uses packages.config.
2.For .net core projects(which uses new SDK-format project file):It uses new PackageReference format as its Package Management format.
More details about it see: Project Type Support
And someone had post this feature request in github, see the issue here.Hope it helps.
Update:
I expected it to pick Microsoft.AspNetCore.Http.Abstractions 2.2.0
Trying deleting the bin and obj folder first,
Then go Tools menu=>Nuget Package Manager=>Package Manager Settings=>Clear All Nuget Caches.(Sometimes it will delete the packages folder in C:\Users\lancel\.nuget\packages, we need to manually create a new packages folder)
Then install the Microsoft.AspNetCore.Http.Abstractions 2.2.0 package separately before installing the Serilog.AspNetCore package. Builds the application and you can check the output .dll by setting the CopyLocalLockFileAssemblies. In my machine it references 2.2.0 version of Microsoft.AspNetCore.Http.Abstractions.dll successfully. Hope it helps:)
I have a problem with these packages which I wanted to use on my Xamarin form using .net standard 2.0
Package 'ExifLib.PCL 1.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Microsoft.Bcl 1.1.6' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Microsoft.Bcl.Async 1.0.165' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Mobilist.AdvancedTimer.Forms.Plugin 1.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'PCLStorage 1.0.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Rg.Plugins.Popup 1.0.4' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Does that mean I can't use this library any more?
Does that mean I can't use this library any more?
No, you should be able to use nearly all libraries that are PCL spec compliant inside of a .NET Standard 2.0 class library. You can checkout the .NET documentation to see list of PCL profiles with their supported platform and their corresponding .NET Standard supported version.
Package warning explanation
With .NET Standard 2.0 and the updated tooling in .NET Core SDK 2+ the .NET team wanted to make it easier to update or make use of .NET Standard libraries. The issue is that not all NuGet packages have been updated to support a version of .NET Standard. So they introduced a fallback targeting .NET Framework 4.6.1 which is nearly 100% compliant with .NET Standard (There are some API that are in the .NET Standard 2.0 spec that are not in .NET Framework 4.6.1 but they can be brought in via NuGet packages if required). So the warning you see is to inform you that the packages do not conform to a .NET Standard version you are targeting and as such may contain API's that are not executable in your runtimes making use of your .NET Standard 2.0 library.
Once you have tested that everything is working as expect you can add the NoWarn="NU1701" to your PackageReference in your csproj which will remove the warning. One thing to note adding NoWarn="NU1701" to a individual package does not remove the warning for dependencies. To remove those warning you must either include them as PackageReferences (via NuGet) or ignore NU1701 warning at a project level.
If you run into fallback issues you can adjust the target framework fallback via overriding the AssetTargetFallback in your csproj to something like:
<AssetTargetFallback>$(AssetTargetFallback);portable-net45+win8+wpa81;</AssetTargetFallback>
I am using Visual Studio 2015 (Pre), Framework 4.5.2
I have the folowing project structure
StorageProject
nuget package Microsoft.WidowsAzure.Storage is installed
This Nuget package has (among others) dependencies on Microsoft.Data.OData, wich is also installed
AnotherProject
Has a refernce on StorageProject
Does not have any nuget package or other refernces (except default references on the framework)
Here is the list of the packages installed in StorageProject
WindowsAzure.Storage 4.3.0
Microsoft.WindowsAzure.ConfigurationManager 3.1.0
System.Spatial 4.3.0
Microsoft.Data.Edm 5.6.4
Microsoft.Data.OData 5.6.4
Microsoft.Data.Services.Client 5.6.4
These are all dependencies of WindowsAzure.Storage, latest versions.
There is no other version of these packages installed anywhere on the solution.
I will focus on Microsoft.Data.OData, but the same problem occurs with Microsoft.Data.Edm and Microsoft.Data.Services.Client 5.6.4
When building StorageProject, the correct version of these dll (5.6.4) ends up in the bin folder of the project.
But when building AnotherProject, the bin folder contains version 5.6.2 of the dll.
Now I passed all day trying to figure out where these dlls come from.
There is a version 5.0.0.0 in the GAC, wich I cannot uninstall. (gacutil yields it is used by something).
I did a file search on C:\ to find that the only place where this version of the dll is (beside the bin folder of my project) is in C:\Program Files (x86)\Microsoft WCF Data Services\5.6.2. If I delete (move) this folder, my project builds "normally" and everything is fine. In fact, in this case OData is not in the bin folder at all. And as far as I am concerned, that's ok this way.
Now the real question(s) :
Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
Can I uninstall it? I don't see it in Windows' control panel.
•Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
This could be due to the fact that the storage client does not depend on a specific version of the Data Service Client. Since Specific Version is set to false, the GAC will be searched first during compilation, any version will be considered "acceptable", and no other version will be exported.
•Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
It could be installed due to a variety of reasons. The Azure SDK contains this as well. So if you ever installed the Azure SDK, it could have come with that.
•Can I uninstall it? I don't see it in Windows' control panel.
Looks like this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs. For that, you would have to again figure out which installation brought this assembly with it and check whether that is needed or not.
According to this article, the version of a referenced dll is embedded in the exe file.
Using ProcExp, I can see that the runtime loaded dll is indeed the latest dll available on my machine, but I'm interested to know the linked version.
As a side note, I built the project using the VS9 msbuild, and interested in the VC runtime (msvcr90.dll) version. In the VC9 redist folder it is 9.0.30729.1, runtime the .4926 is loaded.
My questions are:
Is there any tool with which I can extract the dll version linked to (from the dll/exe)?
Which version does VS link to by default? The one found in its redist folder?
Thank you.
Dependency Walker might do it.
Actually, Dependency Walker seems to not read (or at least display) the version linked in the file.
But I found that I can use mt.exe from the Windows SDK or ResEdit to read the embedded manifests.
Also, to summarize my findings (targeting amd64 using msbuild with the Windows SDK for Win7, which seems to use VS9 (SP1?) libs):
Without special effort, VS9 (non-SP1) version 9.0.21022.8 of the CRT is written in the embedded manifest. Maybe this is a VS9 platform baseline.
Runtime the newest dll gets loaded, according to the SxS policy (good read can be found here, along with the article referenced in the question).
People seem to had problems when the appropriate policies are not installed (via the redist package for example), see here and [here] and 4[here]5.
The latter SO tells that if _BIND_TO_CURRENT_VCLIBS_VERSION=1 is defined, then the linker would link against the VS9 SP1 CRT (version 9.0.30729.1), which as noticed before, is indeed in the redist folder.
For future account, it would be nice if:
There would be a table with CRT version X.Y. introduced in OS/SP/etc Z.W.
If one could know that what is a safe version to target, which is possibly available on most users machines by default.