Build:
.net core 3.1, asp.net core 3.1.3.
Deployment mode: Self-Contained
Target Runtime Win-x64
RedyToRun, single file.
User: win 10 x64, 1903, 18362.788
Its a simple ASP.NET Core 3.1.3 service that runs locally with users. It should not need to have .NET Core runtime installed (as far as I understand it).
It runs smoothly upon installation. User side, my test VMs and my own development environment.
Yet a handful of users have reported that "after not using it for a while" (say a week) they receive the message box saying "To run this application, you must install .net core. would you like to download it now?"
The weird part is: Even if runtime is installed, it keeps asking for it.
It's self-contained, not runtime dependent, this should not be needed.
Has anyone else had this issue or ideas?
It would seem that issue was that the files extracted into the temp directory was partially cleaned up by windows.. causing the application to crash and burn due to missing files.
Intersting issue that was solved in 3.1.4
Related
I've developed an application in .NET 5.0, also, I've a Setup Project to install this application in my clients.
My steps are:
1.- Publish the .NET 5.0 Application.
2.- Compile the Setup project.
3.- Install the setup.exe generated in "2" in the client.
But when I try to install the program in my client, windows says "This installation requires the 5.0.0(x64) version of .NET Desktop Runtime... So I've to download and install the SDK in every client.
My question is: There is some way to avoid this SDK installation? Can I embeed the .NET Desktop Runtime in the .NET 5.0 App or in the Setup Project?
Thanks in advance.
See .NET application publishing overview, specifically publishing a self-contained application. That way all necessary framework files will be included in your application, and you will not the framework to be installed. This will increase the disk requirement a bit if .Net 5 is already installed, since some files will be duplicated.
The alternative is to bundle the the .Net framework installer in your installation script. This will cause the setup-file to be quite a bit larger, unless the script downloads the framework on demand. But it may save some disk space in case there are multiple applications that use .Net 5.
Go on projet Menu/ projetct properties / publish / require components / uncheck you frameWork .
I am working on an app for NET 5 and because NET 5 isn’t released built into windows the main suggestion I have found is to create a contained app with the NET 5 runtimes. The issue with this as I understand it is that this can lead to security issues if new releases are not made and there are issues in NET 5.
So the question is which version would take priority.
A. The App contained NET5 runtimes.
Or
B. Newer Version NET5 runtimes installed in the Windows System separately.
For apps with self contained deployment, the only runtime version being used is the one bundled with the app itself. In that way, the apps are well isolated and side by side (3.1 apps can live nicely with 6.0 apps without breaking each other).
If you want an app to use the common runtime installed, you have to publish it with framework dependent deployment.
If your goal is to resolve vulnerabilities in self contained deployment, make sure that,
Your app can auto update itself
You publish new releases of your app whenever (likely to be monthly) Microsoft publishes a new runtime version.
I am running a custom EntityFrameworkCore version which has some added functionality which I require. Since Thursday 2019/07/25 I am getting MissingMethodException on 3 of my 4 app service plans: dev, stage and production. The test, stage, and production environment are in sync and contain the same exact code. It is therefore very odd that the test environment still works. I also have integration tests set up in the Azure Devops pipeline. The pipeline performs the following tasks: use dotnet, dotnet restore, dotnet build, dotnet test, dotnet publish. And all tests succeed. It is only on the app service that the same requests do not function.
No publish was done to the test, stage, and production environment since
2019/06/28.
The test environment has the same code as the stage, and production environment and functions properly.
Only as recent as 2019/07/25 it stopped working on dev, stage, and production. Before that: everything fine.
The end-to-end integration tests all succeed on the on-premise build server using the Azure Devops pipeline.
It's cliché but, it works locally.
This is very scary that something which functions properly for a month suddenly overnight stops functioning entirely. Without any change in code.
I read that the MissingMethodException points to a DLL problem (System.MissingMethodException: Method not found?). The MissingMethodException occurs in the custom code so a DLL problem seems logical, but I cannot figure out why then does everything still work on the test environment and why did it work before! How can I properly diagnose this?
netcoreapp2.2
.NET SDK 2.2.105
Microsoft.AspNetCore.App 2.2.0 (implicit)
Microsoft.AspNetCore.Mvc 2.2.0
Custom
EntityFrameworkCore based on EntityFrameworkCore-release-2.2
branch
Apparently .NET Core has a dependency on EntityFrameworkCore. Because of this dependency installing a .NET Core SDK comes supplied with its own Microsoft.EntityFrameworkCore DLLs. This isn't a problem as long as my custom EntityFrameworkCore DLLs are of a higher version than the ones installed by the SDK. But the versioning they apply does not seem to be the versioning of EntityFrameworkCore but rather that of the runtime used.
Last week behind the scenes an update happened to the API apps. This meant that the 2.2.6 runtime was installed. This runtime has EntityFrameworkCore DLLs with a higher version number than my custom one. Because of this a sudden switch of DLLs used by the application happened and a custom method was no longer found which lead to the MissingMethodException.
I diagnosed the problem after installing the latest .NET SDK. This caused the latest runtime to be installed and my solution to behave in the same way locally as the ones deployed. I opened the Modules window (Debug -> Windows -> Modules) and then realised what was happening.
This means I no longer need self-contained deployments, but it's probably worth it to look into it nonetheless to avoid breaking changes due to random updates.
Our client has complained about the count of .dll files in the .NET Core app we made for them. Their dissatisfaction persists even after we explained that this is how .NET Core works.
Now I do understand their position completely, my jaw dropped too when I created the package for the first time:
Note how small the scroll bar is. Most of the library names begin with Microsoft. or System. - those that don't are libraries that I use and installed manually.
So the question is: is there anything I can do about this to make our client happy? Aren't the System.* libraries already installed on their machine as a part of .NET Core runtime?
We're targeting .NET Core 1.0 at this moment.
You can create two types of deployments for .NET Core applications:
Framework-dependent deployment
Self-contained deployment
It seems you need Framework-dependent deployments (FDD).
Portable (FDD) application is similar to the traditional .NET Framework application. In this case, a certain version of the .NET Core Framework (also known as shared framework, .NET Core Runtime, redist) should be on the target computer, and when the host starts, the process will load Core CLR, Core FX from the frame folder.
Artifacts of the same Portable Application for different versions of the .NET Core platform
You can see what Directory structure of published ASP.NET Core apps should be
To run Portable applications, at least one .NET Core Runtime (shared framework) must be installed on the target machine. The framework files (s) are stored in the C:\Program Files\dotnet\shared folder.
Core is designed to do this. In old .NET Framework apps, there's a runtime dependency on .NET Framework, i.e. the end-user must have the version of the .NET Framework the application targets installed on the machine as well. Core takes a different approach; it brings everything it needs into the build. As a result, you can drop this folder on any machine, no matter how it's set up and "run" it. (Now technically, you need dotnet.exe in order to run it, unless you build as an executable, but that's just to run the main app DLL.)
Anyways, this is by design, and it's actually much better when you think about it. Your app has just the dependencies it actually needs and nothing else. You don't have to worry about external things like what version of .NET Framework is installed, etc.
That said, I know there's some third-party applications (mostly commercial) that can enable you to "bundle" DLLs or even package up everything into a single executable. However, I'm not sure how compatible, if at all, these are with .NET Core. Still, if your client insists, I'd just see if you can find some tool that does that and essentially "hide" the DLLs.
I use VS 2010 C# Express
The file is digitally signed (signed/verified with signtool)
Target framework: .NET Framework 4 Client Profile
.NET Framework 4 Client Profile is installed
I'm uploading the exe to a simple static html page
If I (or anyone) click on the download link get the message above
Right-click -> Save Target As... works OK
I can run the file without issues after downloading
May I ask why you are targeting .NET 4.0 Client Platform specifically? Why not go ahead and target to one of the 4.5 versions? Is there a requirement to target a discontinued release of .NET?
Within that link and this one under the 'Additional Information' section, there are statements that indicate an 'in place update' to .NET 4.0 is made to migrate an already installed .NET 4.0 Client Platform to the .NET 4.0 Full Install -- there doesn't appear to be anything written to indicate that 4.0 gets installed by the 4.5 installer, if it's not already installed on the system.
Therefore, all machines with .NET 4.5 installed would have replaced the mentioned 'target framework' of .NET that you're building with something that no longer exists on those machines ... which I believe might account for the popup error received. Can you, at least, try to target one of the 4.5 versions of .NET and update the executable to download on your server? Try again and see if the error goes away? If it does, then the problem that you are facing pertains to .NET Client Platform not (or longer due to 4.5 update) being installed on the client machines.
If that's the case and .NET 4.0 needs to be targeted, then you might need to target the Full 4.0 version instead of the Client Profile version. Or just move to one of the 4.5 versions.
I'd venture to guess that the problem is not within the executable itself but somewhere in the delivery of it into the web page or in the delivery of it back down to the end user; especially considering the program will run without issue once it's downloaded.
Have you completely vetted that process? You mention 'simple static html page' - elaborate on that a bit and you might get more suggestions that will lead you toward a proper solution. Web server used? Technology involved? Personal machine running apache or the like? or some website generator? or something like Wordpress? or some other web hosting company and their products? If the problem lies therein, then further details would be nice to have to help you deduce what is causing issue.
As I'm sure you're aware, that particular error message appears to be presented mostly to products that utilize products created with or included libraries requiring .NET 2.0, 3.0, or 3.5 - since they are (by default) no longer pre-installed on newer systems released with Windows 8+ ... a simple test to rule out the possibility would be to simply install the .NET 3.5 installer and see if the problem magically goes away - if it does, then you may need to do a bit of further research on the 'delivery mechanism' - read, web server used - technology it requires - etc ...
If that's way off ... perhaps this is an x86 vs x64 problem? 32bit app running on 64bit OS? something along those lines? A simple test would be to create 2 executables: one that is configured to build all output as x86 and one to build all output as x64 - see if both behave the same or if there is a difference, and move forward from there.
I believe that in this situation, you will need to play around and run a few tests before getting to the bottom of it. Good luck to you.