I just converted a project from MVC 4 to ASP.NET Core 1.0. This project does some pinvoke on a 32bit dll and when I try to debug it, I get that bad image exception.
If I deploy it using dotnet publish -c Release -r win7-x86 it works perfectly fine, but I can't debug it or run through visual studio.
You need to either publish the app as standalone app 32bit or, if it's a shared framework app, then you need to start it with a 32 bit dotnet.
If you already have the app running in 32 bit mode, then you can attach VS to it.
If you want VS to always use the 32 bit dotnet then you have to uninstall the dotnet in program files (or just remove it from the system PATH) and then install a dotnet that's 32 bit, making sure it's on the PATH. It's important to note that system PATH takes priority in Windows so adding something to the user's PATH will not work unless you remove the old one.
PS: I assume you're running on a 64 bit OS. Otherwise, you get the 32 bit dotnet by default.
Related
Context:
I have a MAUI app I have been working on which, for now, only has Windows listed as a TargetFramework in the project file. Until VS2022 17.4 arrived I was able to build and publish this using a publish profile (pubxml) file.
The problem:
Now that 17.4 has dropped, trying to publish the application fails because it no longer uses the pubxml file unless you have more than one platform specified in the TargetFrameworks. I can still publish the app via the command line using -r win10-x64 instead of -a x64 but am completely unable to publish without at least adding android as a TF.
Has anyone else seen this and found a better workaround?
STR:
Create a new MAUI app, enter the project file and remove the line specifying the non-Windows TFs, try to publish using gui.
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 try publish ASP .NET Core2 app.
App is work in visual studio 2017
dotnet build -c Release completed without error
dotnet publish -c Release
Has error
Cannot find compilation library location for package 'Hangfire.MemoryStorage'
But Hangfire.MemoryStorage is _Libs\Hangfire.MemoryStorage.dll not a package
build compiles all your .cs files mainly
publish also compiles all your view files into a single .dll file. So it validates your views as well.
So, If you have an error only in the publish and not in the build, there most probably must be a bug somewhere in your views. Even if the app worked in visual studio, there might be a run time issue somewhere if the bug is in a view.
Regarding the Hangfire.MemoryStorage library. The last update was three months ago. There have also been past issues with this library related to the code not updated for the latest version of .net core. So, I don't think he has released the stable version for .net core 2.0 yet (assuming you have the latest version of the app installed).
Using Visual Studio 2017 (RC), I am trying to setup a project that uses ASP.NET Core, but with the .NET 4.6.2 library.
This is a supported configuration:
Visual Studio will then create a default project; but it doesn't run:
This is without changing a single line in the project: the VC2017 template just does not work.
I tried the following:
- Different versions of the .NET framework
- x86, x64, AnyCPU
- Clear the NuGet cache
- 'Repair' options on Visual Studio's installer.
My understanding is that the error is a x86/x64 mismatch. But since I didn't change a single file from the template, there has to be something else wrong.
Installing ASP.NET Core on .NET Core works perfectly, so the problem is limited to using the regular .NET framework.
Any ideas?
I have the same problem too. But I just found the solution.
In ".csproj" I change some things:
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<!--<RuntimeIdentifier>win7-x86</RuntimeIdentifier>-->
<RuntimeIdentifier>win10-x64</RuntimeIdentifier></PropertyGroup>
And I enable the 64-bit version of IIS Express.
I had problems like these when I restored stuff to a new laptop.
I mindlessly I copied files from my old profile directory to a directory with the same name, but that isn’t a profile directory on the new machine.
A part of this process involved a cloud backup service that my wife bought for me but that I never actually set up right. That also copied files to new locations without my paying attention to what was happening.
I still don’t know (yet) exactly how the machine keeps track of which versions of frameworks and tools to use in the various application directories, but I can report what I did that finally allowed me to create new .NET Core apps on the new machine.
I deleted everything in this directory that was older than today.
%USERPROFILE%.nuget\packages
Again, pretty mindless. I don’t know, (yet) if all that was necessary. Maybe just deleting one or two of the files/directories would have worked. Regardless, I was very happy to see that I could create and develop .NET Core apps on my new machine.
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.