Skip to content
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

Unable to compile using build.cmd file #2714

Closed
Simon-IT opened this issue Mar 5, 2020 · 22 comments · Fixed by #2718
Closed

Unable to compile using build.cmd file #2714

Simon-IT opened this issue Mar 5, 2020 · 22 comments · Fixed by #2718
Assignees
Milestone

Comments

@Simon-IT
Copy link
Contributor

Simon-IT commented Mar 5, 2020

.NET Core Version: 3.1.200-preview-015002
Windows version: 10.0.18363
Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes/No
Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? No

Compiling using build.cmd, I'm getting the error: "The .NET Core SDK cannot be found. Verify that it is installed and that any version specified by global.json matches the installed version"

Trying to compile by Visual Studio the error is:
"error NETSDK1045: The current .NET SDK does not support targeting .NET Core 5.0. Either target .NET Core 3.1 or lower, or use a version of the .NET SDK that supports .NET Core 5.0."

It seems that Net Core 5 version is required, but no version is available for download.

Thank you.

@lindexi
Copy link
Member

lindexi commented Mar 5, 2020

@Simon-IT Add https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json source

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 5, 2020

Mmmh, are you sure that this affects compiling the code by build.cmd file ?

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 5, 2020

@lindexi Sorry, but I was misled by the image. The path that you has mentioned already exists under Options->NuGet Package Manager->Package Sources..

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 5, 2020

Compiling by Visual Studio (16.5.0 Preview 5, but it is the same with 16.4.5) the error is: C:\Program Files\dotnet\sdk\3.1.200-preview-015002\Sdks\Microsoft.Net.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(127,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 5.0. Either target .NET Core 3.1 or lower, or use a version of the .NET SDK that supports .NET Core 5.0.

Using build.cmd the first error is: D:\Sources\NetFoundation\dotnet\wpf\src\Microsoft.DotNet.Wpf\src\System.Xaml\System.Xaml.csproj : error : The .NET Core SDK cannot be found. Verify that it is installed and that any version specified by global.json matches the installed version.
D:\Sources\NetFoundation\dotnet\wpf\src\Microsoft.DotNet.Wpf\src\System.Xaml\System.Xaml.csproj : error MSB4236: The specify SDK 'Microsoft.NET.SDK' has not been found.

@weltkante
Copy link

weltkante commented Mar 5, 2020

Do you have the preview version of VS installed? I do and didn't have problems running build.cmd, I'm wondering if using the preview is currently a requirement. As far as the SDK is concerned the build.cmd should be downloading it I think. If you ended up interrupting the build.cmd download for some reason you may have to clear the git repository and/or user folders since partial downloads/installs are not always recoverable. See here what I had to do to repair a broken build.cmd download.

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 5, 2020

@weltkante I've installed both VS version (16.5.0 Preview 5 and 16.4.5). I've follwed you suggestions for git repository clean up but nothing is changed.
During the build.cmd these files are downloaded:

  • dotnet-api-docs_netcoreapp3.0-0.0.0.2-win64-x64.zip
  • msvcurt-c1xx-0.0.0.8-win64-x64.zip
  • net-framework-48-ref-assemblies-0.0.0.1-win64-x64.zip
  • net-framework-472-iltools-0.0.0.1-win64-x64.zip
  • strawberry-perl-5.28.1.1-1-win64-x64.zip

Nothing about NET 5...

@deanchalk
Copy link

Im having the same issues, and cannot build despite installing every imagineable SDK and having the latest preview VS 2019

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 5, 2020

Well, I'm not alone in the dark....

@weltkante
Copy link

weltkante commented Mar 5, 2020

Did you manually install a 3.x or 5.x preview SDK in the past? You might want to uninstall that, some previews seemed to be in a "bad state" and maybe you are picking up the wrong SDK due to this, happened to me in the past.

Alternatively you could try downloading the SDK the build.cmd downloads for you here (this is the installer version, the build.cmd downloads the zip under the same URL - generally you can take the sdk url downloaded via build.cmd and replace zip with exe to get a corresponding installer). Remember that you'll have to manually uninstall those when you no longer need them.

If that also doesn't work, I'm also contributing to winforms repo and they have a build-local script which installs some 5.x SDK - maybe having built winforms made my machine being able to compile WPF. So if you are desperate try cloning winforms and building it first.

Otherwise you'll have to wait for someone from the WPF team to look into this.

@vatsan-madhavan
Copy link
Member

vatsan-madhavan commented Mar 5, 2020

I'm not convinced that we have to install anything...

I initially thought that installing specific SDK's globally might help, like these ones:

I decided to boot up a new VM on Azure and installed a fresh copy of VS 2019 Enterprise using just this VSConfig file + the above mentioned SDK's (both x86 & x4) to validate my assumption. (BTW VS installs .NET Core 3.1.101 x64 SDK - so that's 5 installations of .NET Core SDK's total). I also installed Git 2.25.1 and MSBuild Structured Log Viewer in addition to these.

I expected the build to pass easily. To my surprise, the build failed with the same error that you are seeing. 🙁

{
  "version": "1.0",
  "components": [
    "Microsoft.Component.CodeAnalysis.SDK",
    "Microsoft.Component.MSBuild",
    "Microsoft.Component.VC.Runtime.UCRTSDK",
    "Microsoft.Net.Component.4.6.2.SDK",
    "Microsoft.Net.Component.4.7.2.TargetingPack",
    "Microsoft.NetCore.Component.DevelopmentTools",
    "Microsoft.NetCore.Component.SDK",
    "Microsoft.VisualStudio.Component.Git",
    "Microsoft.VisualStudio.Component.NuGet",
    "Microsoft.VisualStudio.Component.Roslyn.Compiler",
    "Microsoft.VisualStudio.Component.Roslyn.LanguageServices",
    "Microsoft.VisualStudio.Component.TextTemplating",
    "Microsoft.VisualStudio.Component.VC.ATL",
    "Microsoft.VisualStudio.Component.VC.ATLMFC",
    "Microsoft.VisualStudio.Component.VC.CLI.Support",
    "Microsoft.VisualStudio.Component.VC.CoreIde",
    "Microsoft.VisualStudio.Component.VC.Modules.x86.x64",
    "Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
    "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
    "Microsoft.VisualStudio.Component.VSSDK",
    "Microsoft.VisualStudio.Component.Windows10SDK.18362"
  ]
}

Earlier today, a colleague (no GitHub ID) pointed me (in an internal email) to dotnet/msbuild#2532, which got me thinking that MSBuild SDK resolution is really where something is going wrong. He was able to work around it by setting MSBuildSDKsPath, but I don't think that should be necessary.

Turns out that the solution is rather simple. global.json needs one more entry, like this, to tell MSBuild which SDK version to use.

diff --git global.json global.json
index 796f4987..8ec2788d 100644
--- global.json
+++ global.json
@@ -1,25 +1,28 @@
 {
   "tools": {
     "dotnet": "5.0.100-alpha1-015515",
     "runtimes": {
       "dotnet": [
         "2.1.7",
         "$(MicrosoftNetCoreAppInternalVersion)"
       ]
     },
     "vs": {
       "version": "16.1"
     }
   },
+  "sdk": {
+    "version": "5.0.100-alpha1-015515"
+  },
   "msbuild-sdks": {
     "Microsoft.DotNet.Arcade.Sdk": "5.0.0-beta.20154.1",
     "Microsoft.DotNet.Helix.Sdk": "5.0.0-beta.20154.1"
   },
   "native-tools": {
     "strawberry-perl": "5.28.1.1-1",
     "net-framework-48-ref-assemblies": "0.0.0.1",
     "dotnet-api-docs_netcoreapp3.0": "0.0.0.2",
     "msvcurt-c1xx": "0.0.0.8",
     "net-framework-472-iltools": "0.0.0.1"
   }
 }

Once this hint is added, MSBuild is able to use the 5.0.x SDK downloaded dynamically as part of the build process just fine.

I uninstalled the 5.0.x and 2.1.7 SDK's and was able to build the repo again successfully (with just the global.json change in place).

@rladuca
Copy link
Member

rladuca commented Mar 5, 2020

@vatsan-madhavan Do we know why this is needed? What makes our build machines so different to the clean VM you made?

@vatsan-madhavan
Copy link
Member

vatsan-madhavan commented Mar 5, 2020

Our build machines build with -ci which seems to behave very differently.

That said, sdk.version should be used in general - if -ci build always succeeds without it, then it's getting lucky.

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 6, 2020

@vatsan-madhavan Great job ! Compiling by build.cmd file works well now. But remain a problem in Visual Studio 2019 ( both 16.5.0 Preview 5.0 and 16.4.5). When the Microsoft.Dotnet.Wpf solution is loading, all projects are not fully loaded with these errors:

..csproj: error: The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found.
Detailed Information:
Unable to locate the .NET Core SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.

@weltkante
Copy link

weltkante commented Mar 6, 2020

can't guarantee it'll work, but try deleting the hidden .vs folder, it may have been caching stuff in there

@deanchalk
Copy link

deanchalk commented Mar 6, 2020

OK, Ive got much further, but I still have a strange issue:
I have one laptop where everything builds fine
I have another laptop, with the same config and fresh clone from the repository, which fails at a specific place every time (have cleaned out folders and started fresh several times)

Generating Code...
OtherAssemblyAttrs.cpp
UIAutomationClientSideProviders -> C:\Projects\opensource\wpf\artifacts\bin\UIAutomationClientSideProviders\Debug\net
coreapp5.0\UIAutomationClientSideProviders.dll
Generating Code...
resources.vcxproj -> C:\Projects\opensource\wpf\artifacts\bin\resources\Win32\Debug\resources.lib
.NETCoreApp,Version=v5.0.AssemblyAttributes.cpp
precomp.cpp
LINK : fatal error LNK1104: cannot open file 'MSVCURTD_netcore.LIB' [C:\Projects\opensource\wpf\src\Microsoft.DotNet.Wp
f\src\DirectWriteForwarder\DirectWriteForwarder.vcxproj]
dllentry.cpp
wpfgfx.def
Creating library C:\Projects\opensource\wpf\artifacts\bin\wpfgfx\Win32\Debug\wpfgfx_cor3.lib and object C:\Project
s\opensource\wpf\artifacts\bin\wpfgfx\Win32\Debug\wpfgfx_cor3.exp
wpfgfx.vcxproj -> C:\Projects\opensource\wpf\artifacts\bin\wpfgfx\Win32\Debug\wpfgfx_cor3.dll
wpfgfx.vcxproj -> C:\Projects\opensource\wpf\artifacts\bin\wpfgfx\Win32\Debug\wpfgfx_cor3.pdb (Partial PDB)

Build FAILED.

LINK : fatal error LNK1104: cannot open file 'MSVCURTD_netcore.LIB' [C:\Projects\opensource\wpf\src\Microsoft.DotNet.Wp
f\src\DirectWriteForwarder\DirectWriteForwarder.vcxproj]
0 Warning(s)
1 Error(s)

Time Elapsed 00:03:09.14

Does anyone have any idea what this issue is ? could it be that this laptop has an AMD processor (Surface :Laptop 3)

Thanks

Dean

@Simon-IT
Copy link
Contributor Author

Simon-IT commented Mar 6, 2020

@deanchalk I've had the same problem. On wpf repository, try the git clean -xdf command and then build.cmd. For me it has resolved much problems.

@deanchalk
Copy link

@Simon-IT - thanks for the advice, but unfortunately that didnt fix anything :(

@deanchalk
Copy link

deanchalk commented Mar 6, 2020

Ahhh, ok I solved it (somehow)
I went onto Visual Studio installer and installed anything related to c++ development that I hadnt already installed. Im not sure which piece was missing (I had previously followed the github guidance) but now it builds - thank goodness :)

@vatsan-madhavan
Copy link
Member

@deanchalk, see the contents of the .vsconfig file I mentioned in an earlier comment (#2714 (comment)). Save it into a text file (say, wpf.vsconfig), and let the VS installer consume it. It will add the components one needs to build the repo.

image

@vatsan-madhavan
Copy link
Member

vatsan-madhavan commented Mar 7, 2020

try the git clean -xdf

😉

GIT_ASK_YESNO is especially handy when using VS + git clean. Also, killing lingering build-processes before git clean tends to be a good idea.

WPF relies on Arcade SDK and scripts during build, which tends to download stuff under %userprofile\.netcoreeng. Sometimes clearing this cache and the NuGet cache can be handy to 'reset' the build.

This is what my clean.cmd looks like:

@setlocal enabledelayedexpansion 
@echo off

REM Set GIT_ASK_YESNO=false to prevent interactive
REM Q&A from git like "Unlink of file '.vs/foo' failed. Should I try again? (y/n)"
REM
REM GIT_ASK_YESNO is defined at 
REM https://github.com/git/git/blob/d62dad7a7dca3f6a65162bf0e52cdf6927958e78/compat/mingw.c#L188
REM No documentation as far as I can tell
REM 
REM Call to setlocal earlier would ensure that this setting is local to 
REM the lifetime of this batch-file's execution
set GIT_ASK_YESNO=false

REM msbuild.exe, dotnet.exe, vbcscompiler.exe can all be holding 
REM locks on files - kill all corresponding processes and their descendants. 
for %%i in (msbuild dotnet vbcscompiler mspdbsrv git sh wish) do (
    taskkill /f /t /im %%i.exe
)

REM Actually run 'git clean'
git clean -xdf -q

if /i "%1"=="/deep" (
    call rdir %userprofile%\.netcoreeng
    nuget locals all -clear
)

@lihas
Copy link

lihas commented Sep 5, 2021

I was getting fatal error LNK1104: cannot open file 'MSVCURTD_netcore.LIB' error too.
I downloaded wpf.vsconfig mentioned in developer guide (https://github.com/dotnet/wpf/blob/main/Documentation/developer-guide.md) with VS2019, and opened it with VS2019 installer.
image

The method is mentioned by @vatsan-madhavan earlier (#2714 (comment)).

I had tried this earlier too but instead of using it with VS2019, I was using it with VS2017, and then using VS2019 command prompt. So be careful when you have multiple installations.

I had to upgrade VS2019 to latest (16.7 didn't work, 16.11.2 (latest at this time) worked).
I then used x86 Native Tools Command Prompt for VS 2019 to build.
.\build

@lihas
Copy link

lihas commented Sep 5, 2021

Here are the steps which worked for me.
1. Clone repo instead of downloading zip file - https://github.com/dotnet/wpf.git
2. Use latest VS2019
3. Install all dependencies mentioned here - "corefx/windows-instructions.md at master · dotnet/corefx (github.com)"
4. See wpf.vsconfig step - #2714 (comment)
5. Open "x86 Native Tools Command Prompt for VS 2019"
6. Run build .\build.cmd

@ghost ghost locked as resolved and limited conversation to collaborators Apr 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants