I have a .net framework 4.8 library I have been working on for months in VS19. The project is configured to "Register for COM interop" (which runs regasm.exe on the dll).
Recently (in last few days) I installed VS22 and have been playing around with some .net core projects in here.
I have come back to my original library in VS19 which when compiling now reports (during the regasm call):
Cannot register assembly "X:\<removed>\my-lib.dll". Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
I get the same result from manually trying to register the dll or trying to load and compile the project in VS22. I have installed all VS19 updates and rebooted the computer, no change.
It is my understanding that netstandard 2.1 has nothing to do with framework and netstandard is not specifically mentioned anywhere in my code or config. The gacutil /l output shows netstandard 2.0.0.0 is installed but nothing else.
It would seem the installation of VS22 may have shifted something in my environment and I'm not sure how to correct it?
Related
I have a SDK styled .Net class library which compiles properly on my local machine, however fails on build server.
The contents of .csproj are
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net35;net40;netstandard1.0</TargetFrameworks>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<Version>1.5.6</Version>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
</Project>
The error displayed is:
NETSDK1045: The current .NET SDK does not support targeting .NET Standard 4.0. Either target .NET Standard 2.1 or lower, or use a version of the .NET SDK that supports .NET Standard 4.0
I have .NET Core 3.1.113 installed on build server and .NET 5 installed on local machine.
Note: If I remove netstandard1.0 from TargetFrameworks then build succeeds on both the machines. However I want my library to target .net standard 1.0 as well.
I cannot understand why v4.0 is treated as .NET Standard 4.0 on build server. Can anyone let me know what the problem might be?
Remove the following line from your .csproj file:
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
This overrides the version value that the SDK infers from TargetFramework which will interfere with your definition of net3.5 and so on - you were actually building .NET Framework 4.0 twice and then override netstandard1.0 to .NET Standard (inferred TargetFrameworkIdentifier) to 4.0. Newer versions of the SDK may have different inference logic which may be a difference between 3.1 and 5.0 SDKs but this is an error in the csproj nonetheless.
If your build logic relies on TargetFrameworkVersion being defined in the project I suggest you try to change your build logic - this is VERY DANGEROUS to have in a modern csproj file where you rely on TargetFramework and TargetFrameworks (plural). You can also try to move it into a separate <PropertyGroup> with an always-fals-condition (e.g. <PropertyGroup Condition="'$(ThisIsToWorkAroundBuildScripts)' == 'True'">)
I cannot understand why v4.0 is treated as .NET Standard 4.0 on build
server. Can anyone let me know what the problem might be?
That is quite strange and I have not seen that issue before. And there is no info about .NET Standard 4.0 and I did not know why VS treats v4.0(net framework 4.0) as net standard 4.0. Maybe your there is some problems about your server environment.
Please follow these:
1) First, please use dotnet --list-sdks under CMD to check if you installed net core 2.1 sdk or any other versions. And actually, net core 2.1 sdk could support the previous sdks including net standard 1.0. Maybe you would better install net core 2.1 sdk. Also, you could install the latest Net Core 3.1 Sdk.
2) check system environment variable, and find whether there is a variable called MSBuildSDKsPath, if so, please delete it. Then, restart.
3) delete bin and obj folder under the build server. Also, I suggest you would better use Build Tool for VS to build your projects on the server rather than dotnet build. dotnet cli does not contain the tool for net framework. What's more, your project is multi-targetframeworks, it could build net core and net standard, and also you have to download net framework sdk.
That is too complex, you could install the Build Tool for VS2019(more likely a lightweight cmd which integrates dotnet, net framework, all vs environment). Also, install the Net desktop build tool and net core build tool workload, also install the related sdks.
When you finish it, delete bin and obj folder, type this under Build Tool for VS command:
msbuild xxx\xxx.csproj -t:clean,restore,build
I try-converted a windows form app to .NET 5 and I was able to build and run it last week. Now, it has an error building.
NETSDK1148 A referenced assembly was compiled using a newer version of Microsoft.Windows.SDK.NET.dll. Please update to a newer .NET SDK in order to reference this assembly. APP C:\Program Files\dotnet\sdk\5.0.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Windows.targets
Target framework for the csproj is <TargetFramework>net5.0-windows10.0.19041.0</TargetFramework>
I'm unsure what to change/update. Error is a little vague.
Removing Microsoft.Bcl.Build from the project fixed this issue. See https://github.com/dotnet/sdk/issues/16360
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.
I just starting to use Visual Studio 2010 and .NET 4.0. I created a new WPF project a DLL built for .NET 2.0. When I build the project, I get a bunch of warnings like this one:
The referenced assembly
"MicroFour StrataFrame Business...processorArchitecture=MSIL"
could not be resolved because it has a dependency on
"System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
Please remove references to assemblies not in the targeted framework
or consider retargeting your project.
When I reference a project I created that targets 3.5, it can't find any of the namespaces (during compile), though they show up in the object browser and intellisense correctly shows them.
Is there something I'm missing that needs to be done to reference an older .NET assembly?
There is very little point in targeting the client profile for .NET 4.0. The download is 41MB, the full version is 48MB, only 15% bigger. Unfortunately it is the default in VS2010, just change it with Project + Properties, Application tab, Target framework combo.
The client profile does make a lot of sense if you target 3.5, the full install is ~350 MB. The huge difference is explained by the prerequisites, .NET 4.0 requires at least XP SP3 or Vista SP1. But 3.5 installs on any version of Windows > 2000. The 3.5 installer thus contains lots of the required updates for unmanaged Windows components used by .NET. The web installer lessens that blow considerably btw.
Your 2.0 assembly has a reference to System.Web. The reference is being automatically forwarded to your target framework, 4.0. So it is attempting to use System.Web, version 4.0.0.0. The problem is with 4.0 (actually this started with 3.5), there is now the notion of a client profile. The client profile has a smaller set of reference assemblies, anything web/server related has been removed. This is to make the .NET framework a smaller/simpler download for end users.
With VS 2010 and .NET 4, the client profile is being pushed a lot harder, MS really wants us to use it. So your .NET 4 project is targeting the client profile by default. Your referenced assembly wants System.Web, so in that case you need to switch to the full profile.
I have a Windows .net solution that is deployed with a Visual Studio Deployment project.
My exe is a win32 app that runs fine on either a x86 or x64 windows.
However I included a merge module (*.msm) from a third party vendor which is available in a x86 and x64 version.
Now I could copy my whole deploy project and just change the msm, but I'm a lazy guy and the best thing would be to include both msm's in my installer and only install the module which fits the processor of the client machine.
Is there a way to do this with Visual Deployment projects?
Merge Modules seem to lack a Condition property like included exe / dll files have.