I am trying to run a .Net Core 2.1 Website through IIS. I had to reinstall IIS recently and was getting the error when navigating to my website:
Handler "aspNetCore" has a bad module "AspNetCoreModule" in its module
list
So I downloaded and installed the Windows Hosting Bundle for the relevant version of .Net Core from here https://dotnet.microsoft.com/download/dotnet/2.1
I then restarted IIS but I am getting the same error.
I noticed in the IIS Modules page for the ASP.Net Core Website I am trying to run, there is still no AspNetCoreModule listed. I take it it should be appearing here after installation of the bundle?
Any ideas what could prevent the installer adding this module?
This error can occur if the AspNetCoreModule is not installed properly in IIS on the computer that is running the Microsoft Dynamics NAV Web Server components. To resolve this issue, open Programs and Features in Control Panel and check whether Microsoft .NET Core Windows Server Hosting is installed. If it is installed, repair it from Programs and Features, by selecting it, choosing Change, and then choosing Repair.
I also noticed that the SDK downloaded in the link you provided has x64 and x86. please check if you had downloaded the correct version.
Related
I need to upgrade an application in a Windows Server 2016 machine, and in order to do so they require ASP.NET Core runtime to be v3.1.1 or higher. I have installed v6.0.8, but when running the application installer it seems to still be detecting the old version and therefore can't run the update. I checked the new version is installed using "dotnet --list-runtimes" and it shows OK. I have also checked the registry, and confirmed the new version is there. I have restarted IIS as well. But so far nothing. What could I possibly be missing? I don't have control over the application code, so I can't access the runtime json file to modify version used as I have seen in some solutions.
Any help, appreciated. Thanks.
We're about to deploy a netcore 2.0 application on production, but we need to install .NET Core Runtime and SDK first. Is a restart needed for the installation to take effect? Since it's production, we don't want that to happen.
We installed the following from here
x64 Installer (SDK)
x64 Installer (Runtime)
Windows Server Hosting (Runtime)
There was no need to restart the machine and nothing blew up (:
If you are creating a Windows Service using the .NET Core SDK (Microsoft.Extensions.Hosting.WindowsServices) and deploying it in the target machine you need a restart (atleast a log off depending on the application you are running). Here is what happens.
Install .NET Core Runtime
Deploy a windows service.
You will notice that the command line in the windows service will be "dotnet "
Start the service. It will fail because it cannot find the tool "dotnet".
This is because the service control manager (services.msc) is not aware of the dotnet command being added to the path. So you can either do a log off (or)restart to make sure things work.
You could just install Windows Server Hosting Bundle without SDK on your production machine (actually it should be).
But then you'll get 502.3 error, and you could add a element as follows into {YourProject}.csproj file, and then it'll work like a charm.
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Ref: https://github.com/dotnet/coreclr/issues/13542
With respect to either:
.NET 6.0 Desktop Runtime (v6.0.2) - Windows x64 Installer Link
.NET 6.0 Runtime (v6.0.2) - Windows x64 Installer Link
... a reboot is not required.
I didn't have time to test:
ASP.NET Core 6.0 Runtime (v6.0.2) - Windows Hosting Bundle Installer Link
ASP.NET Core 6.0 Runtime (v6.0.2) - Windows x64 Installer Link
... but agree with #MuqeetKhan that you should ideally have both a dev && testing lower environment before performing a production install. (Though, I also understand with smaller co's, that due to constraints & battles lost; this may not be possible.)
I have a windows forms application running on .NET 4 that communicates with a WCF web service. The application is compiled to run with X86 as the platform target. The application was deployed on a network of hundreds of computers, and there are only a couple, that happen to have a windows XP version installed (Microsoft Windows Embedded POSReady 2009, service pack 3 to be more precise) that launch the error "Common Language Runtime detected an invalid program" upon calling the constructor of the WCF proxy class object. In order to isolate the problem, I created a small console application that the only thing it does is to call the constructor of the web service proxy class, like:
ItesWebServiceClient m_webService = new ItesWebServiceClient("BasicHttpBinding_IItesWebService");
And the exception is then thrown:
stacktrace output
The same console app runs on all other computers, even the ones with the same windows version.
We've already tried repairing and re-installing .Net framework on the failing computers but so far nothing fixes it. I also used the PEVerify tool to validate MSIL and ran the code in debug mode (no optimizations) as suggested on other posts.
Is there something I'm missing? could there be a key .Net framework component or hot fix that needs to be installed?
Thanks
Ok it turns out that the person who was re-installing the .Net framework on the machines was always installing the .net client profile version. Uninstalling that version and installing the full .net 4 version solved it.
Sorry if this is not suitable place to post it.
I have completed my program and already build it. it has no problem running on my laptop but when i run on other laptop, there is an error appear
To run this application you must first install one of the following version of
.NET framework: v4.0.xxxxx
Contact your application publisher about obtaining the appropriate version of .Net framework
How do i check my program using which kind of .Net framework for running the program? can i just disable it?
You need to download and install the .Net Framework on your other laptop.
If you have an installation project, you can have this happen automatically when the application is installed on another computer.
This is Edited from the OP. This is a VB .NET 4.0 WinForms application. There is a mysql datasource involved with this project. The target CPU is set to any. Problem: When running this application on any computer that has VS 2010 installed along with the mysql connector it runs flawlessly. When installing on a virgin system(ie. No developer environment installed) but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately. So to fix the issue I install the mysql connector MSI. This immediately fixes the issue on the client system and it runs. The problems is that as you can see below from my Installer setup that the 2 needed DLL files for MYSQL are actually included in the installation package so should not need to be installed separately. So Why is it that using that installer from the images do I need to install the mysql connector? Any Ideas? Below is a screen shot of the References the program uses and from what I believe I do not need to deploy any of those DLL files with my application other than the 2 MYSQL DLL files. So why is this failing?? Below are images showing the project references as well as the Installer Files that are being installed in the applicaiton folder. As shown in the image the 2 mysql dll files are to be put in the application folder. There is also a screen shot showing each dll's properties for in application folder.
You answered your own question.
but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately.
You don't need to install the connector msi package, but you do need to include the two DLL files in the application's directory. Anytime you have some dependency, you need to deploy it with your application.
Edit solution quoted from my comment:
From your update it sounds like you have a version mismatch on the
assemblies, and the references are set to Specific Version = True.
Check the version number of the assemblies on your developer machine
in the output directory, and check the version you are installing on
the client system. (You can just hover over the DLL to read the
version on the ToolTip). You can try to set Specific Version to false
by right clicking your reference and selecting properties, or simply
ensure you deploy the same version of assemblies. Your program is
looking for the versions its compiled against