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

The app is not compatible #107

Closed
JamesBlack2 opened this issue Dec 6, 2018 · 38 comments
Closed

The app is not compatible #107

JamesBlack2 opened this issue Dec 6, 2018 · 38 comments
Labels
Bug Product bug (most likely)

Comments

@JamesBlack2
Copy link

我使用VS2019新建了一个测试用的.net core的控制台应用程序,但是当我把这程序发布后生成的文件复制到Win7 service 1,7061的 32位系统想远行时,却提示文件版本与系统不兼容,就是将其设置兼容性再跑时,也不行。是否VS2019预览版并没有完全将.net core的运行打包在一起?

下面是app的项目配置。
《Project Sdk="Microsoft.NET.Sdk">
《 PropertyGroup>
《 OutputType>Exe《/OutputType>
《 TargetFramework>netcoreapp2.2《/TargetFramework>
《/PropertyGroup>
《/Project>

@lindexi
Copy link
Member

lindexi commented Dec 6, 2018

You need to install the dotnet core runtime in win7.

你需要在 Win7 的系统上安装 运行时。

Or you can publish the dotnet core application to win7 x86.

或者将 dotnet core 程序发布为 Win7 x86 然后复制到 win7 运行

@JamesBlack2
Copy link
Author

有两个问题:
1)
2>正在还原 H:\Test\WpfApp6\WpfApp6\WpfApp6.csproj 的包...

这个步骤不动了,我是发布到本地的目录上的,这个应该不需要这么久的时间吧。这个步骤在我这至少花了好几分钟。不过后面几次很快,这个我测试了几个工程,第一次都需要好几分钟时间。

2)在那个控制台应用程序,通过发布独立的,是可以正常跑,但是如果是WPF的话,则一打开就会崩溃跑不起来。

WPF的项目配置如下:
《Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
《PropertyGroup>
《OutputType>WinExe
《TargetFramework>netcoreapp3.0
《UseWPF>true
《AssemblyName>MyCore3App《/AssemblyName>
《Platforms>AnyCPU;x64;x86《/Platforms>
《/PropertyGroup>
《/Project>

@karelz
Copy link
Member

karelz commented Dec 6, 2018

In general, we take feedback and questions only in English. If it still needs a response, can someone please post English translations? (automated are mostly fine)
We can then update the original posts with appropriate text.

Thank you!

@rladuca rladuca added the needs more information Not enough information has been provided. Please share more detail as requested label Dec 6, 2018
@JamesBlack2
Copy link
Author

There two questions:

1:

           2 > Restoring packages of H: \Test\WpfApp6\WpfApp6. csproj...

In this step, I publish it to the local directory, which took me at least a few minutes. I tested several projects, all of then are took several minutes to compile the first time. It's just a small project. would bigger projects take longer?

2:In that console application, it can be run normally. but if it is WPF project, it will crashes at the start to run.

@rladuca
Copy link
Member

rladuca commented Dec 7, 2018

@JamesBlack2 It would be helpful if you could upload a sample project to a GitHub repository and then share that repository with us here. Then we can examine the exact code that you are having issues with.

@JamesBlack2
Copy link
Author

Thanks,i has update the sample project to github now.
https://github.com/JamesBlack2/WpfApp6.git

@lindexi
Copy link
Member

lindexi commented Dec 7, 2018

@JamesBlack2 I think you build the application in the win10 and run in win7.

@lindexi
Copy link
Member

lindexi commented Dec 7, 2018

@JamesBlack2
Copy link
Author

It is,build in Win10 and run in Win7.it must be build in Win7 if i want it run in win7 or other win version?
I saw that guide like that,and build to try run,the result is the same too.the project is make by command "dotnet new wpf -o WalterlvWpfApp"

@shadowaltar
Copy link

我使用VS2019新建了一个测试用的.net core的控制台应用程序,但是当我把这程序发布后生成的文件复制到Win7 service 1,7061的 32位系统想远行时,却提示文件版本与系统不兼容,就是将其设置兼容性再跑时,也不行。是否VS2019预览版并没有完全将.net core的运行打包在一起?

下面是app的项目配置。
《Project Sdk="Microsoft.NET.Sdk">
《 PropertyGroup>
《 OutputType>Exe《/OutputType>
《 TargetFramework>netcoreapp2.2《/TargetFramework>
《/PropertyGroup>
《/Project>

I used VS2019 to create a .Net Core console app for testing: when I put the files built to Windows7 Service 1,7061 32bits, it prompts that the file version is incompatible with the system. Nor would it work if I turn on the compatibility mode.
Does it mean that VS2019 Preview doesn't bundle the .Net Core runtime?

@karelz here you are.

@boyjiwen
Copy link

boyjiwen commented Dec 7, 2018

I also encountered this problem.
Created a wpf program based on .net core3.0, which can run normally on this machine and other WIN10 machines, but it can't run under WIN7 (x64 and x86 try, the result is the same). Also try to install the .netcore3.0 runtime on the WIN7 machine, the result is still the same, the WPF window does not display and an error window pops up.
After the x86 app has replaced some of the api-ms-win-core-xxxx.dll, the WPF window is displayed, but the error window pops up, and the program exits after clicking.

@randyliang1
Copy link

我在win 7上使用 .net core3.0 发布wpf 工程,也遇到这个问题。

@LiangWeixin
Copy link

Me too, I created the .net core 3.0 program under win7, but it can't run. Is it that some of my configurations are wrong?

@JamesBlack2
Copy link
Author

is you build you project in win7 ,and you run system has setup .netcore runtime? @lindexi

@boyjiwen
Copy link

boyjiwen commented Dec 7, 2018

@randyliang1 @LiangWeixin I can run it in win7 sp1

image

See 如何创建一个基于 .NET Core 3 的 WPF 项目 - walterlv

将基于 .NET Framework 的 WPF 项目迁移到基于 .NET Core 3 - walterlv

Is the running environment locally installed with VS2019 or net core3 sdk?
After I compile the WIN7 device, the local can run normally, and I can't run it on another WIN7 machine without a development environment.

image

@boyjiwen
Copy link

boyjiwen commented Dec 7, 2018

@lindexi
Your program seems to be a system loaded with a runtime.
Whether vs2019 can put the dependent runtime into the application, not the system's runtime.

@boyjiwen
Copy link

boyjiwen commented Dec 7, 2018

  1. dotnet new wpf -o wpfapp

  2. publish
    image

  3. Tested in different systems (no .netcore runtime installed)
    WIN10: OK
    image

WIN7 64 : ERROR
image

@rladuca
Copy link
Member

rladuca commented Dec 7, 2018

I can't tell what the actual error you're experiencing is. However, WPF for .NET Core currently has a dependency on the VCRuntime (See the getting started guide and #37). The fact that various machine are behaving this way with a previously published application seems to be indicative of running into this requirement.

If you can verify that your issues are spawned from the same (or similar) issue and that installing VCRuntime on all machines that you want to run your application on solves the issue we can close this as a duplicate of #37. We are already working to address that specific issue.

@boyjiwen
Copy link

boyjiwen commented Dec 7, 2018

@rladuca
After installing VCRuntime x86 and x64 (Microsoft Visual C++ Redistributable for Visual Studio 2017) on the WIN7 machine, the problem still exists.

image

Please advise how can I find my program error? Have tools?

My requirement is that the program can run under a machine that does not have the .netcore runtime installed.

Also, will the final version support Windows XP? When is the final version plan released?

@rladuca
Copy link
Member

rladuca commented Dec 7, 2018

@boyjiwen You can run this under a debugger to get us a stack trace along with the inner exceptions (if they are nested). I suggest grabbing WinDbg so that you don't run the risk of bringing a dev environment like Visual Studio in.

I'll try replicating this today on a clean Win7 SP1 VM with nothing installed and the published application copied over.

@karelz Does .NET Core have a list of Windows versions that will be supported for .NET Core 3?

@rladuca
Copy link
Member

rladuca commented Dec 7, 2018

When I took the base project from dotnet new wpf and did an initial publish selecting win-x86 as the target, it did publish a correct executable, but the binary api-ms-win-crt-l1-1-9.dll (as stated above by @boyjiwen ) seems to be the incorrect bitness.

I'm not sure exactly what's going on right now, I'll have to dig deeper and get some help from people more familiar with the publish step in VS, but this seems like a bug, though not in WPF specifically. Perhaps I am still doing something wrong myself.

What worked for me is to publish from the command line. On your dev box, just do the following dotnet publish -r win10-x86 --self-contained in the directory where the solution is. The output from this ran on my Win7 SP1 machine with no issues.

I appreciate everyone's help in overcoming any translation barrier and providing us with effective instructions to reproduce the problem!

@rladuca rladuca added Bug Product bug (most likely) and removed needs more information Not enough information has been provided. Please share more detail as requested labels Dec 7, 2018
@rladuca
Copy link
Member

rladuca commented Dec 7, 2018

I was able to make this work in VS2019 by doing the following:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UseWPF>true</UseWPF>
    <SelfContained>true</SelfContained>
    <RuntimeIdentifier>win7-x86</RuntimeIdentifier>
  </PropertyGroup>

</Project>

When I published this from VS and ran the output on Win7 SP1 VM with only the VCRuntime2017 installed, the application loaded as expected.

I am getting some more guidance as to a sample I can point to that is more definitive, but if you try that you should be able to get it working.

@karelz
Copy link
Member

karelz commented Dec 7, 2018

@rladuca Supported OS versions in core repo: https://github.com/dotnet/core/blob/master/os-lifecycle-policy.md (3.0 is still TBD, but you can check 2.1)

@JamesBlack2
Copy link
Author

image
image

I has got the dump file by TaskMgr and update to github,that may be help: https://github.com/JamesBlack2/WalterlvWpfApp.git

the app can pop the notice message box normally ,but when click ok later it crashed.
the app published by this command.dotnet publish -r win10-x86 --self-contained,the vcruntimer has installed.

@lindexi
Copy link
Member

lindexi commented Dec 9, 2018

@JamesBlack2 you should not publish in win10. I can not find any in your dump.

@boyjiwen
Copy link

boyjiwen commented Dec 10, 2018

@rladuca @karelz

After Windows 7 installs VS2019, WPF programs that could not be run before can now run normally.
And confirm that the WPF program uses the DLL under the application directory.

image

Now find a way to check if the WPF program depends on a package in VS2019.

@boyjiwen
Copy link

@rladuca @karelz
Tested with 6 WIN7 machines, VC2017 Runtime can run on the machine.

Before the test machine installed VC2017 can not run (downloaded from Microsoft officially),

  1. Normal after installing VS2019;
  2. Cannot run after deleting VC2017 runtime, normal after reinstalling VC2017.
      There may be a problem with the runtime library downloaded from Microsoft.

The problem should be the same as #37. Will this problem be solved in the final version?
We plan to transfer the current WPF program to .net core3. When will the final version be released?

@lindexi
Copy link
Member

lindexi commented Dec 10, 2018

@boyjiwen do not impatient to update WPF to dotnet core 3. I update some WPF application but I find some application be crash in running.

@boyjiwen
Copy link

@lindexi
The .net framework45 installer will fail to install on some Win7 machines.
Therefore, our program has two runs of .net35 and .net45. Under WIN7, the launcher will launch that version in the system environment. But there are still many users who can't run our programs.
At the same time, we also need to provide users with no installation version.

I tried mono before, but only supported Winform. I wanted to extract the .net framework to the installation package before, but I didn't find the relevant information.

If this can solve the dependence on the .NET runtime under WIN7, DAU should be able to increase by 15%~20%.

Why not use C++/Qt/DirectUI or Html5 solutions?
In the past, we used C++/Qt solutions, but the development efficiency was low, the resource investment was not as much as mobile development, and it was too difficult to recruit experienced Windows C++ developers in China.

First we have UWP products and then ported to WPF. After using WPF, we found that development efficiency and product stability are better. At present, our WPF program reaches millions of daily active users.

Therefore, we are more eager and hope that the final stable version of .net core3 will be released soon.

@rladuca
Copy link
Member

rladuca commented Dec 11, 2018

@boyjiwen, we intend to fix the vcruntime dependency prior to RTM. We don't have a specific time frame for that otherwise.

WPF does not depend on VS2019 in any way at runtime. I have repeated the publishing experiment multiple times on clean Win7 VMs and VCRuntime is the only dependency to a properly published WPF application.

@JamesBlack2 I haven't had a chance to check out the latest dump file you posted. I will do so tomorrow.

@lindexi
Copy link
Member

lindexi commented Dec 11, 2018

@boyjiwen Try to use turbo studio.

@boyjiwen
Copy link

@rladuca @lindexi
Copy vcruntime140.dll to the released package, it can run normally on Win7 machine without VCRuntime installed.

@rladuca
Copy link
Member

rladuca commented Dec 12, 2018

@boyjiwen Yes, that is expected. The eventual solution for RTM is something relatively similar to that, but with some more considerations in mind.

For instance, the framework itself cannot carry vcruntime140.dll, because an application may have its own version of the DLL. Therefore, the framework needs to have a renamed version of it, which complicates matters in linking.

Eventually, we will contain a private version of the DLL that will be brought along during a publish and not conflict with the application's use of its own VCRuntime (if it happens to use it).

For a specific application being published, you can definitely copy along VCRuntime as you can be 100% sure that it's the right thing to do.

@boyjiwen
Copy link

@rladuca
Today builds a WPF version with vcrtime, tested internally, with another problem found on several machines:

The program can be run and the MessageBox is successfully called, but after confirming it, it crashes.

image
image
image

@JamesBlack2
Copy link
Author

@rladuca I use @boyjiwen to operate, put the runtime in the corresponding directory, I try our company's WIN7 systems to test, some of the machines can run normally, but some machines are not, also like @boyjiwen the app will crash. and then,i created a home version of Win7 in VM, and run the program,but i can not run, i even not see the crash dialog box notice.
If necessary, you can operate my computer remotely to see did you have encountered such problems。

image

@boyjiwen
Copy link

@JamesBlack2 Your problem is encountered when I installed the virtual machine today, installed NetcoreRuntime, using the dotnet command.
Dotnet --list-runtimes => Failed to load the hostfxr.dll
After installing the system update patch KB2533623, you should be able to solve the problem.

At this time, I realized that the .net core may be related to the system update patch. After installing KB2533623, the program can display Messabox, but it will crash and display in KernalBase.dll.
I checked a few machines and found that the high version of KernalBase.dll works fine, but the lower version of KernalBase.dll will pop up Messabox and then crash.

After updating other system update patches (re-verification is the update patch), it can run normally.
At this time, the viewing system has improved the version of KernelBase.dll.

@rladuca @karelz @lindexi
Is there any plan to reduce the reliance on system update patches?
A large part of the WIN7 user system update function is turned off. When the relevant update patch is not installed, the WPF runs incorrectly.

I hope that these dependencies can be reduced later. In this case, Windows software development has developed an efficient UI framework to improve development efficiency, which may attract more enterprises and developers to participate in Windows development.

@stevenbrix
Copy link
Contributor

stevenbrix commented Apr 4, 2019

There is a lot of awesome discussion here, thank you everyone for contributing! I'm not sure it's possible to remove the dependency on those two KB updates, they deliver necessary components that are not currently present on the machine. I'm going to close this as a duplicate of #37, if that is incorrect please respond and we can continue the discussion.

@boyjiwen can you please file an issue regarding the message box crash (if one doesn't already exist)? Thanks!

Duplicate of #37

@ghost ghost locked as resolved and limited conversation to collaborators Apr 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Product bug (most likely)
Projects
None yet
Development

No branches or pull requests

9 participants