-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating to 16.4 from 16.3.x causes build issues with WPF project file. #2274
Comments
Same issue here
Workaround: |
Yes i added the following global.json alongside my solution:
|
But this is hopefully not the solution we have to accept... |
@olivegamestudio, @zplan, are you sure that .NET 4.6.1 and .NET 4.7.2 targeting packs are installed for you respectively? |
@livarcocc, @nguerrera, @chabiss, is it expected that 3.0.100 or 3.0.101 SDK vanishes when upgrading from Dev16.3.x --> Dev16.4? |
Yes double-checked. When I change my target to 471 it compiles okay. Seems that the latest update has made that the minimum .NET version? Unfortunately, I can't target 471 and need 461. But this all worked under the last 16.3 update, it's only broke since updating to 16.4. |
Yes, beginning with VS 16.3, VS will only "root" the one SDK it comes with. If VS installed an SDK and you upgrade to a VS that brings a newer SDK, it will remove the older SDK and add the newer one. There is ref counting so that if you install an SDK standalone, it will never be uninstalled by VS. VS gets one ref count and the standalone install gets another. If you have scenarios where you need multiple SDKs, you have to install the other ones standalone. This came after a TON of feedback against leaving SDKs behind from VS upgrades. I am advocating that the global.json default policy should allow roll forward to any newer version by default. You now have control over the roll forward, but the default is very restrictive and will only roll across the xx in A.B.Cxx if the matching version is not found. |
Im having the same issue. This is currently blocking my work. I checked VS Installer and I have all required targetting packs and NetCore SDK 3.1 What is the proposed solution / workaround or is it possible to rollback a Visual Studio update? |
Installing the 3.0.101 SDK and using global.json to force it, is a viable workaround that does not require rolling back all of VS, while we look at the issue and work on fixing it. |
It would be very helpful if someone who is hitting this could provide a binlog with the failure. |
See the attached project. I could reproduce it with an almost plain WPF project and a reference to Unit v4.0.1. I know, this is a very old version but for legacy reason I have to stick to this version. Before the VS 16.4 update it was no problem to build the project with this reference. <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
<RootNamespace>Test</RootNamespace>
<AssemblyName>Test</AssemblyName>
<OutputType>WinExe</OutputType>
<UseWPF>true</UseWPF>
<FileVersion>0.0.0.9999</FileVersion>
<AssemblyVersion>0.0.0.9999</AssemblyVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Unity" Version="4.0.1" />
</ItemGroup>
</Project> |
I had the same problem too. I fixed it, as mentioned above, by installing the .NET Core 3.0.101 SDK and adding a global.json file. However, why do I have to install a .NET Core SDK if my project isn't targetting .NET core at all? |
From my experience, that's because you are using the new "SDK-style" projects, which by definition use the .NET Core SDK/build system. When using the old ".NET Framework" project files, it will work fine. |
That makes sense, Siegfried! I am indeed using the new style projects... |
Me as well. But I will NEVER go back to the old csproj style : ) |
I have a WPF project targeting net451 and net472 but using the Microsoft.NET.Sdk.WindowsDesktop SDK using the new csproj format. In VS 16.3.9 it was working, after upgrading to 16.4.1 I have the same issue. Could not find System.Core 2.0.5.0 I have all the targeting pack installed.
If I remove net451 everything works. I can build for 472 successfully, Did you raise the minimum framework version or something? We have both because we always build two versions for customers who don't have an up-to-date framework on their computers. |
I have net40 WPF project with Microsoft.Bcl.Async (important, refers on mscorlib 2.0.5.0). Builds successfully in VS 16.3, but fails in 16.4. |
We were going to update our open source project to use 2019 & .NET Core 3.0 but because of this issue, this is blocking us from proceeding forward with the upgrade. The workaround of installing older SDK and using |
What is the state of this issue: Can we expect a VS update which solves this or what is the plan? |
My VB WPF control libraries have the same problem. Minimal log
The log of failed build task
I solved this issue by adding reference to "mscorlib" in my project. <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<RootNamespace>CompileNetFxWpfWithNetCore31Sdk</RootNamespace>
<TargetFrameworks>netcoreapp3.1;net461</TargetFrameworks>
<UseWPF>true</UseWPF>
</PropertyGroup>
<ItemGroup>
<Reference Include="mscorlib" Condition="'$(TargetFramework)' == 'net461'"/>
</ItemGroup>
</Project>
|
dotnet/corefx#42768 fixes this, which is targeted for 3.1.2 milestone. We release updates at approx. 1-2 month cadence (.NET Core Roadmap]). Note that the last update (3.1.1) was released on Jan 14, 2020, and we hope to release this fix in the following update to .NET Core 3.1 (unless, of course, something unexpected results in a change of plans). |
@vatsan-madhavan |
@vatsan-madhavan maybe it is possible to release this earlier? or is there a preview version? |
@leecow Can we share a better timeline for when we'll ship dotnet/corefx#42768? |
@ds1709 as started before, you should use 3.0.101 until this is fixed in 3.1.x: { "sdk": { "version": "3.0.101" } } |
I'm building WinForms application with WPF ElementHost. And after creating
|
As long as we are limited to 3.0 as sdk version, we are not able to use .NET Core 3.1 as target framework for applications (e.g. for having mixed mode assembly support). Is this the case or do I get something wrong? |
Ok, after some research I found, what problem is in PresentationBuildTasks.dll assembly. I desided to debug it to find the problem. Clonned repository, build it and... It works without any problem. So, my question is: what's the point to hold the fix, why can't you just release it? |
Are there any news on this? |
We already moved to python for development platform, Microsoft really keeps on disappointing as a development platform, python is amazing in fixing bugs ASAP |
+1 for not working on 3.1.2 |
Please give us some information here. We are completely stuck and cannot move from .NET Framework to .NET Core, since we need .NET Core 3.1 features to make this transition. What is the plan behind? We do not get any feedback. |
I want to join to the others. Please move on! At least give us a little piece of information... Is it ongoing? Won't be fixed? |
There is a fix queued for this in the next update (3.1.3) which should be available shortly. I also want to offer some context on the delay, which is a failure on our end. The problem and the solution turned out to be a bit nuanced and hard to track down. We did fix this in 3.1.2 as part of dotnet/corefx#42768 or so we thought. To understand what really happened, you have to understand how a .NET Core SDK is put together, where the fix had to be made, and how the fix makes its way from point-of-fix to point-of-consumption. The point of fix-consumptionThe WindowsDesktop SDK, the one that is referred to in WPF and WinForms projects by the line The fix was needed in
Where is the fix made?
How do fixes 'move' from one repository to another in the .NET Core build process?To explain this, I want to share a snapshot of how various repositories are interconnected.
It can be observed in the flow-diagram above that This sets up a perpetual cycle of builds, like this: -> This perpetual cycle was not a serious problem during active product development of .NET Core 3.0/3.1 - we create a lot of builds, builds take a lot of time to complete, and the overall progress tends to be relatively slow. But once the product stabilized and switched to servicing, this perpetual-build engine couldn't be allowed to continue. To break this cycle, the edge from We have only created a handful of servicing builds since .NET Core 3.1 was announced (we are just about to release 3.1.3), and we didn't take this change into account. More importantly, we failed to grasp the implications for What this change (the disablement of the edge from
What happened ?The above flow process works fine for the vast majority of scenarios. The all-up product construction (
By the time we understood the full scope of what happened and how, 3.1.3 was almost ready and it was looking like the fix may not make it into the schedule. We decided to delay 3.1.3 a bit and rebuild it to take the fix into it anyway. Ultimately, this was all that was needed - #2670 (well, followed by an across-the-board rebuild, resetting the progress we had made in 3.1.3 so far across the board, retesting, etc.). /cc @rladuca |
Fantastic response @vatsan-madhavan , thanks for this honest evaluation / retrospective. We are looking forward to this 3.1.3 release and will provide feedback immediately once it has been released (but now have full confidence it's fixed!).
Can you shed some light on the ETA or is it too early to tell? Again, thanks for the response and hopefully this ticket can be closed soon. |
@GeertvanHorrik as things stand, we are hoping for for 24/03/2020 (assuming that factors outside our control do not change this plan, of course 😄). |
To clarify, as a part of Visual Studio 16.5 update? |
.NET Core Runtime/SDK installers are also available separately, so you don't have to wait for a VS update if you don't want to. (Assuming the fix "being in 3.1.3" means its fixed in the SDK and not in VS) |
I can confirm this has been fixed in 3.1.103, great work, thanks! |
Closing as this is now fixed. |
Using Visual Studio 16.6, migrating WPF app to target .netcore3.1(.300). Cannot compile with error below: Error MC1000 Unknown build error, 'Could not find assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Either explicitly load this assembly using a method such as LoadFromAssemblyPath() or use a MetadataAssemblyResolver that returns a valid assembly.' MyApp C:\Program Files\dotnet\sdk\3.1.300\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets 225 Is this the same issue? I seem to have most current .netcore (3.1.300) and VS16.6.0. Any suggestions how to get compiled? |
Still, No Fixes Microsoft is working on this issue slower than windows 10, Better you migrate to Java |
@Kerfluffel no this is not the same issue, I suspect System.Web is not part of .NET Core (probably discontinued), so this error would be expected. |
This looks to have regressed with 3.1.400 (16.7 release) |
Same here. All WPF projects that reference DevExpress WPF libraries started failing to build after updating from 3.1.302 to 3.1.400:
|
With .NET Core 3.1.400, Visual Studio 16.7 and targeting net48, I've got the same error compiling from VS or from the command line. |
An open issue where this is being tracked is #3312. |
When building a WPF project the following error is shown, this built fine in the last 16.3.x version that was released.
The project file:
The text was updated successfully, but these errors were encountered: