I'm currently having more issues with packaging using the Windows Application Packaging Project (WAPP).
I desire to package my WPF app into an app bundle compatible with 32 and 64 bit systems. In my own app I added the WAPP and referenced it in accordance with this Microsoft Docs article along with doing the initial setup in the projects properties and making x64 and x86 configurations using the Configuration Manager for my WPF project.
Debugging the WAPP runs normally with no issues. When I move to publishing, I set it for sideloading, select the signature and choose to bundle the Release x64 and x86 configurations.
During the publish process, the x86 build runs first with no issues, but when doing the x64 part I'm met with this error:
There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "C:\Users\UserFolder\Documents\InstallerDemoSourceCode\WPFDemoApp\bin\x86\Debug\netcoreapp3.1\win-x86\WPFDemoApp.dll", "x86". This mismatch may cause runtime failures.
I've spent a while making new Wpf projects and downloading examples of other WPF projects using MSIX and attempted publishing which all ends with the same error which seems to indicate an issue with VS or my PC.
I even tried using the project unchanged from this helpful video, where he was able to build it exactly the way I want to, but am unable to do the same due the this error.
However, I did notice in the x64 build output that the build is using my x86 objects instead of x64. You can even see in the error that the DLL it is referencing is in the x86 folder. Is this a bug potentially?
Any leads would be invaluable
UPDATE #1:
In response to the suggestion from #JonasH I tried to publish the app in AnyCPU mode and received an alternate error instead:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\Users\jacob\OneDrive\Documents\InstallerDemoSourceCode\WPFDemoApp\bin\x86\Debug\netcoreapp3.1\win-x86\WPFDemoApp.dll", "x86". This mismatch may cause runtime failures.
So I was able to fix this by literally re-selecting configurations in the Configuration Manager. i.e. Select the Any CPU Profile reselect all the projects build profiles as Any CPU, rinse and repeat for x64 and x86. This somehow worked?
I'm still unable to publish as Any CPU but all information surrounding publishing Desktop apps (WinForms, WPF, etc) to Any CPU suggests that you need to use x86 and x64 explicitly instead as that option only seems to work for UWP.
Related
I am developing Azure Function in visual studio, it running well locally. When I try to publish to AZ, it gives me failed error: Please change project B target platform to x64 via build configuration manager.
But I already did so, otherwise it can not running, even locally. However, I did not change the target platform to x64 in the dialog after I right click the project B's properties.
Problem is after I make the change there, it did not working even locally. Project A with target platform AnyCPU which reference to peoject B gives me another error: Project A: Could not load file or assembly, Project B.
Any idea on how this whole thing should work both locally and on Azure. Am I in the wrong place at beginning?
They all in same solution, the executing project call Porject A, and project A call project B
Thanks!
I find that Platform target in Property pages (aka right click on Project, Properties> Build) controls the platform indeed. Leave it as Any CPU and change Configuration manager to x64, projects are built as x86, i.e. the preference of Any CPU. I also find in a brand new project, modify Configuration manager to x64, Platform target is changed to x64 automatically and projects are built into x64 bits.
So I guess running well locally happened because your projects actually targeted at x86 before. After Platform target changed, x64 doesn't work well due to the inconsistency of projects platform.
Based on this, I would suggest as #Jeremy said, make sure all project Platforms are set to Any CPU, we could delete x64 platform settings directly for a clean configuration.
If you choose to set all project platform to x64, follow steps below.
VS consumes x86 runtime by default, to debug x64 functions we have to download x64 cli(containing runtime) and configure manually.
Visit cli release note to download latest x64 bits(1.x for v1 .NET Framework Functions, 2.x for v2 .NET Core Functions). For example, for v2 functions on OS Windows, we could choose Azure.Functions.Cli.min.win-x64.2.4.317.
Right click on your project->Properties, do debug configuration below.
Launch: Executable
Executable: [x64CliPath]\func.exe
Application Arguments: host start
Before publish, don't forget to modify Platform to 64-bit on Application settings in Azure portal.
Background:
Working in C# using the 2.0 framework and setting up an application to use sqlite. When deployed to certain customer machines I get:
Could not load file or assembly System.Data.SQLite.dll
I am under the impression that there should be no client install of SQLite as long as you've placed the above DLL in the runtime directory. I have tried multiple configurations (x86 DLL compiled into a project targeting x86 cpu - failed on both x86 machines and x64 machines | x64 DLL compiled into a project targeting x64 CPU - failed on both x86 machines and x64 machines | both architecture versions of the DLL targeting Any CPU - failed on both x64 and x86).
I am using SQLite version 1.0.98.0. I'm not sure what relevant code I could post as this is an issue with a DLL reference, but I am happy to upload anything needed to foster a reasonable answer. I have no client computer cpu in mind so if I could get this running as x86 targeting x86 CPU that would be great. Any yes, I have already tried that combination using the correct DLL while making sure it ends up in the runtime folder and it still fails. If I could post more than two screen caps I would show the file as well, but alas I cannot.
I have been searching for quite a while and cannot seem to find an example that exactly fits what I want to do. The question has been asked but not solved. I read that the configuration of the DLL is what causes this and that is why I tried both DLL's targeting both processors. Seeing that this question is asked a lot and I still couldn't find my answer I have to assume a lot of people are in the same position as me so maybe we can work this one out together and give the community a great post on solving this issue.
Assembly information for the x86 configuration
Configuration Manager for x86 CPU
Make sure your dll are deployed properly on target machine. Some time setup compiler (Inno Setup) puts all the files in directory structure in same root folder hence .net can not file dll for expected path and hence it throws file not found exception
I've got a project that builds on a build server (TFS), and works fine if the build configuration is x86 or x64. Take that same project, set it to Any CPU, and I get this error:
SGEN: An attempt was made to load an assembly with an incorrect format: ...\....dll.
It is also worth mentioning that all 3 build configurations work fine on my local development machine.
Any thoughts on what I should be looking at?
Your error message occurs when you try to load an assembly built for x64 in an x86 process or vice versa.
An assembly that is built for AnyCPU can be loaded in an x64 or x86 assembly because it will JIT to x64 or x86 depending on the bitness of the process loading it.
There are a LOT of possible causes for this error related to TFS builds. My recommendation is to search SO for "SGEN: An attempt was made to load an assembly with an incorrect format" and start stepping through the solutions already posted. Seriously this is a very common problem with different solutions based on your post-build events, setting your build workflow toolplatform, etc.
I am working on a Web Application on a Windows 8 64 bit machine using multiple existing libraries. I want to use two C# DLLs referencing one native DLL. Both C# DLLs are compiled for 64bit usage and tested in test applications.
My web application references both C# DLLs and is supposed to run on IIS 8.
I added the two C# DLLs as references to the project and the native DLL manually to the bin folder of the web app. Whenever I build and run the solution I get the exception shown in the title.
I know that this is a sign for a problem regarding 32 bit and 64 bit code running in one process. Therefore I tried all different build configurations but the result never changed.
I created a console application doing exactly what I'm trying in the web app and it worked flawlessly.
The Web application with the exact same settings however throws the exception, this is what is really confusing to me.
What I tried so far:
Change application pool setting to "enable 32-bit applications"
Build all DLLs with Any CPU, 64Bit or x86 target
Check the corflags of all DLLs
I can provide an export of the project to everybody willing to help me get this configuration running!
I really appreciate every bit of help!
I presume you tried with setting Target Platform (Build option in project properties)?
Also, take a look at this article:
http://www.codeproject.com/Articles/383138/BadImageFormatException-x86-i-x64
I got the same issue on my application. It was fixed after I perform the following:
* Granting permission for the "Anonymous" user in my web site folder.
* Changing the application pool from ".NET v4.5 Classic" to ".NET v4.5".
All I can offer is some help in determining what isn't loading. If it's a dev server it might be worthwhile to install the appropriate sdk to use the Fusion Log Viewer. If that isn't an option you can turn on assembly binding logging from the registry as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogFailures"=dword:00000001
"LogPath"="c:\\bindFailureLogs\\"
just be sure to turn it off when you're done, there is a performance penalty using the assembly bind logging. Make sure the folder exists before you enter the registry key and recycle the application pool of the application for the logging to start. This will provide you a detailed list of what dll (or dependency since it's not always readily apparent if it's a dependancy or the dll listed in the error message) didn't load and where it tried to load it from.
Your partitioning of the applications fixing the problem suggests that there are multiple dependencies on the assembly targeting different versions and since only a single version of an assembly can be loaded into an app domain some dependency isn't being satisfied. For managed assemblies you could use an assembly binding redirect, but I don't know what the unmanaged equivalent of that would be if it even exists.
I have a C# project which contains a reference to ScintillaNET. Unfortunately ScintillaNET likes to detect the architecture of the machine and loads the native DLL based on the running architecture. That means that my project must be pre-compiled into x86 and x64 versions (I can not use Any CPU due to the above detection).
The problem is that my build server is x86-only. Is there a way I can compile a .NET assembly in x64 mode on an x86 machine? As far as I am aware the toggle simply forces the computer to load the assembly for the required architecture and doesn't actually output any architecture-dependent code at compile-time, however, when compiling under Mono 2.10.6 on the build server I get errors such as:
"error CS0016: Could not write to file `ScintillaNet', cause: AMD64"
I can't use CorFlags.exe to change the PE headers as this is a Linux-based build server. Is there any way to do this?
I ended up solving this issue by switching the project back to Any CPU. Since Scintilla will only work in the native architecture regardless of .NET settings, I had to run it as 64-bit on my machine. Originally I had intended to force the architecture to 32-bit to get Edit and Continue and this lead to confusion to how Scintilla detected architectures.
In reality, Scintilla will force itself to the native architecture, but if you build and run under Any CPU the .NET application will work fine. In addition, since I can't run a .NET application w/ Scintilla in 32-bit mode (for Edit and Continue to work) I get no advantage to forcing 64-bit mode on my machine either.