This is a general question but I will describe my specific scenario - My project is a .NET Core 3.0 SignalR Console application in VS19 (same with VS17)
After upgrading everything to Core 3.0 build now fails with:
Error CS1705 Assembly 'Microsoft.AspNetCore.SignalR.Client' with identity
'Microsoft.AspNetCore.SignalR.Client, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60' uses 'Microsoft.AspNetCore.Http.Connections.Common,
Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' which has a higher version
than referenced assembly 'Microsoft.AspNetCore.Http.Connections.Common' with identity
'Microsoft.AspNetCore.Http.Connections.Common, Version=1.1.0.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60'
What I understand is that despite the nuget highest version of Microsoft.AspNetCore.Http.Connections.Common being 1.0.0.0, for some reason Microsoft.AspNetCore.SignalR.Client requires 3.0.0.0 which does not exist (yet).
How can I tell VS to use Microsoft.AspNetCore.Http.Connections.Common 1.0.0.0 instead ?
I tried in my csproj to add specific version to the reference:
<PackageReference Include="Microsoft.AspNetCore.Http.Connections.Common" Version="1.1.0">
<SpecificVersion>False</SpecificVersion>
</PackageReference>
But nothing changed. I also tried with <SpecificVersion>True</SpecificVersion>, same result :(
Any help ?
Some of the .NET Core prerelease libraries aren't available on the main NuGet feed. You need to add the nightly/dev feed to your NuGet package sources and, hopefully, it should be available there.
The feeds are:
ASP.NET Core
https://dotnet.myget.org/gallery/aspnetcore-dev
.NET Core
https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
To add the feed to Visual Studio
In the Manage NuGet Packages window for your project click on the cog in the top right corner.
In the new dialog click the red 'x' in the top right
Paste the URL above in the "Source" tex box
Give the feed a name (e.g. ASP.NET Core Dev)
Click Update
Ensure the feed is at the bottom of the list (so this is the last one used for packages)
Click OK
Now you can change the Package Source in the NuGet window to either your new feed or "All" and click the 'include prerelease' to see the pre-release versions of the packages.
Related
In Visual Studio 2019, if you right click on a symbol, you can select "Go To Definition". If the symbol is not defined in your code, it will attempt to generate the code from the dll.
When it generates this file, it puts a #region comment at the top of it. This is an example of what my region comment looks like:
#region Assembly Logging.Client, Version=6.0.1.0, Culture=neutral, PublicKeyToken=null
// C:\Users\myUserId\.nuget\packages\logging.client\7.0.0.43\lib\netstandard2.0\Logging.Client.dll
#endregion
The key part is that it says Version=6.0.1.0. I opened up the NuGet file, and, on the properties of Logging.Client.dll, the version says 7.0.0.43:
So, my question is: Where does the version number shown on the line of the #region comment get pulled from?
NOTE: I looked at this similar question, but the steps of deleting the existing packages, restarting Visual Studio and rebuilding did not resolve my issue: Latest version of nuget package still not up to date
Where does the “Go To Definition” version number come from?
It is from AssemblyVerion attribute on VS and it is set in your nuget project by the nuget author.
Please see the below interpretation.
===================================================================
I assume that logging.client nuget package is your own nuget package.(created by yourself)
This is a normal behavior of the nuget and assembly mechanism. It is not an issue and it is just defined that way by the author of the package.
These make sense and are defined by the author when the nuget package is created and can be modified by the author. It's just that they have different functions from each other to deal with the mechanism of nuget.
The Version=6.0.1.0 is the assembly version of the dll which used by framework. It is a built-in version number which is used during build or used at runtime. It can only be accessed by vs internally. To be precise, this is its real version number.
And File Version 7.0.0.43 is the version of the dll, which is used for external display and can be accessed externally.
And Product Version 7.0.0.43 means the nuget package version which also can access outside VS.
So, they all are defined by the author as he want.
See this official document about the function of these attributes: Use AssemblyVersion and AssemblyFileVersion attributes.
They all have professional terms in VS:
AssemblyVersion means 6.0.1.0, AssemblyFileVersion means File Version 7.0.0.43 and NugetVersion means Product Version 7.0.0.43. And they can be also access outside VS.
====================================================
In my side, I created a net standarad class library project called ClassLibrary1.
Right-click on your net standard class library project, right-click on your project Properties-->Package
1）
The Assembly version is used under Logging.Client, Version=6.0.1.0, Culture=neutral, PublicKeyToken=null.
When you install that package on the main project, on the main project, click on the dll on the References and you will see the internal version 6.0.1.0 under the Properties Window.
And when you install this package on a net framework project with packages.config, it will shows on the csproj file:
<ItemGroup>
<Reference Include="ClassLibrary1, Version=6.0.1.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\ClassLibrary1.7.0.0.43\lib\netstandard2.0\ClassLibrary1.dll</HintPath>
</Reference>
The version is used by the internal framework and at build or runtime and only be seen in VS.
2)
The Assembly File version is the file name, it shows on the dll's properties and shows outside VS as File Version which you described on the case.
3)
The Package Version is the version of the nuget package rather than the assembly dll version. They're different concepts.
In your side, it shows like this:
<ItemGroup>
<Reference Include="ClassLibrary1, Version=6.0.1.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\ClassLibrary1.7.0.0.43\lib\netstandard2.0\ClassLibrary1.dll</HintPath>
</Reference>
And in the dll's properties, it shows as Product Version.
Overall，it is not an issue and each of them has a meaningful and specific function. If you want to change this, you should change your nuget project's Properties-->Package as I said above, modify them as the same. Then, repack its as nuget package.
I have two versions of same project. Both have a reference to the same DLL, but at different locations.
The first csproj includes:
<Reference Include="Microsoft.Expression.Effects, Version=4.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\3rdParty\Microsoft\Microsoft.Expression.Effects.dll</HintPath>
</Reference>
The second csproj, which uses a NuGet package, includes:
<Reference Include="Microsoft.Expression.Effects, Version=4.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\3rdParty\NuGet\packages\Microsoft.SDK.Expression.Blend.1.0.0\lib\net45\Microsoft.Expression.Effects.dll</HintPath>
</Reference>
I try to understand the reason for that. Can I use the same hint path for them? Which to choose?
First Project
The Microsoft.Expression.Effects.dll was copied to the ..\..\..\3rdParty\Microsoft\ directory manually and then referenced in Visual Studio by e.g. right-click on the project then Add > Reference... > Browse... and selecting the DLL in the corresponding directory.
Your former co-worker most likely copied the library from the local installation folder of the Expression Blend SDK (or somewhere else) to a folder in the solution, so that it is always available. Otherwise the library would be referenced from the local installation folder and everbody working on the project would have to install the SDK to the same location or else the reference would not be found.
Second Project
In the second case a NuGet package was installed to the project via packages.config. This is just one mechanism to manage packages in your project that stores the information about referenced packages in a file called packages.config in your project. To install a package, right-click the project and choose Manage NuGet Packages.... In the tab Installed, you will see that you use the Microsoft.SDK.Expression.Blend package.
A package can contain a variety of different artifcats like DLLs. The power of packages is that you can manage dependencies much more conveniently than with the common way of referencing DLLs like in the first project. When you install a package, the contained libraries will automatically be referenced in your project file. You do not add or modify these references yourself, the package manager does that for you. Let's have a look at the HintPath.
..\..\..\3rdParty\NuGet\packages\ is the root path where the packages are installed and extracted
Microsoft.SDK.Expression.Blend.1.0.0\ is the root of the concrete package in version 1.0.0
lib\net45\ is the package internal path for libraries for .NET Framework >= 4.5
Can I use same hint path for them? Which to choose?
As you can see, the question is more like whether you should use NuGet packages or reference libraries manually. This depends on the requirements of you project. In general, I recommend to use NuGet packages, since they make it much easier to manage dependencies. However, if there is no package for the library you need, you will have to add references yourself.
A few extensions that I'm using are broken under VS2012 because at some point they were updated to work with VS2013, by changing the version of referenced libraries. At runtime an error like this can be produced:
Could not load file or assembly 'Microsoft.VisualStudio.Shell.12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I see various extensions referencing multiple versions of the same library:
<Reference Include="Microsoft.VisualStudio.Shell.Interop" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.8.0, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Others release an extension per VS version.
Another option, according to this article, is to dynamically load the correct version.
I'd like to help fix these extensions, but what's the proper way to tackle this issue?
So the Visual Studio reference assemblies break down into a few different categories, which you should handle differently depending upon the category:
Interop assemblies: these are the ones like the Interop.* assemblies you listed in your question. Each interop assembly isn't a newer version of the "same" thing, but rather an assembly that contains all the COM interfaces that were added in that version of Visual Studio. Referencing old versions is fine, just don't reference a newer one than the lowest version of Visual Studio you want to target
Editor assemblies, Roslyn: Anything related to the core text editor (assemblies are Microsoft.VisualStudio.Text.Data, Microsoft.VisualStudio.Text.UI, Microsoft.VisualStudio.Text.UI.Wpf, and Microsoft.VisualStudio.Editor) and Roslyn Visual Studio includes assembly redirects that redirect whatever version you're referencing to the version of VS you're actually running in. Once again, target the lowest version that you intend to support.
Microsoft.VisualStudio.Shell.[version]: this one confuses people a lot. How this particular assembly works is for each version of Visual Studio that ships, a new assembly name (with the version in the assembly) is made. Then, in future versions of the Visual Studio, we ship a newer version of the assembly that you target. So again, make sure you're targeting Microsoft.VisualStudio.Shell.[version] with the lowest version you intend to support.
The tricky problem here is the VSSDK project upgrader likes to upgrade your projects to newer versions. Get used to editing MSBuild files by hand to ensure it doesn't do this, or downgrade what it already did. For the final VSIX you ship to users it's often best to either build with an older version of VS to ensure it's not picking up newer stuff by accident. If you want to only use a newer version, then you'll have to find the VS binaries from the older version you wish to use and check those into your source control system to ensure the older versions are still being picked up. Test your VSIX if you go this route as it's easy to make a mistake and reference something newer by accident.
I wrote an article discussing the various assembly versioning policies used by Visual Studio assemblies.
http://tunnelvisionlabs.github.io/vsbase/docs-master/html/edbfd3ce-43f4-4f3f-a90c-bc22bda19fae.htm
In addition, the VSSDK.* NuGet packages use dependency declarations to help you identify the version(s) of Visual Studio each extension can be used with.
The particular version of Microsoft.VisualStudio.Shell you referenced is a Versioned Assembly (per the previous article) and included in the VSSDK.Shell.12 package, with the following description:
This package provides the Visual Studio "Shell" reference assembly used by Visual Studio 2013 and newer.
To easily target both Visual Studio 2012 and Visual Studio 2013, use NuGet to manage your VS SDK dependencies, and ensure the following conditions hold:
Make sure your assembly does not have a dependency on the VSSDK.IDE.12 NuGet package. This dependency means one or more assemblies referenced by your project only work with Visual Studio 2013 and newer.
Make sure your assembly does not have a dependency on VSSDK.IDE.10Only, VSSDK.IDE.11Only, or VSSDK.IDE.12Only. These indicate that your package references one or more assemblies that only work with a particular version of Visual Studio.
Ideally you would only want to install VSSDK NuGet packages which include both the vs2012 and vs2013 tags.
I'm trying to compile the project with targeted framework as ".NETFramework 4.0". But I get the following warning:
The primary reference "XXX" could not be resolved because it has an
indirect dependency on the framework assembly
"System.Runtime.Serialization, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" which could not be resolved in the
currently targeted framework. ".NETFramework,Version=v4.0". To resolve
this problem, either remove the reference "Fdi" or retarget your
application to a framework version which contains
"System.Runtime.Serialization, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089".
I found an earlier (but similar) problem: Visual Studio 2010: Reference Assemblies Targeting Higher Framework Version
Johannes Rudolph found this answer on MSDN's forums ( http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/dfadfb34-5328-4c53-8274-931c6ae00836 ):
However, there're 2 workarounds.
Option 1:
Step1: Unload the referencing project targeting .NET 2.0
Step2: Right click the unloaded project and select edit from context menu
Step3: Add <SpecificVersion>true</SpecificVersion> to the reference.
Below is a sample from my repro solution:
<ProjectReference Include="..\HighFX\HighFX.csproj">
<Project>{8DD71CAF-BEF7-40ED-9DD0-25033CD8009D}</Project>
<Name>HighFX</Name>
<SpecificVersion>true</SpecificVersion>
</ProjectReference>
Step4: Reload the project.
Now your should be able to build within the Visual Studio 2010, there could still be a warning as below, but the build can be successful.
Warning 1 The project 'XXX' cannot be referenced. The referenced project is targeted to a higher framework version (3.5)
Option2:
Use the command line tool csc.exe to build each of your source file, which won't prevent the building.
I've uploaded an MVC3 website and I'm getting this error:
Could not load file or assembly 'System.Web.Helpers, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its
dependencies. The system cannot find the file specified.
Having seen this before I know that it's an issue where the libraries I need aren't there. I have to bin deploy.
However I can't find the "Add Deployable Assemblies" option when I right click the project.
And according to this answer:
Starting with MVC 3 Tools Update we are now using Nuget package
references, which means that your project is automatically
bin-deployable. Since the tooling gesture is no longer necessary it
was removed from VS 11.
So why hasn't my application been "automatically bin-deployed" if this is the case?
Any suggestions?
Install Visual Studio 2010 Service Pack1 and you will get the option.
http://iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio