I have an issue with these two famous warnings which are raised during compilation of our solution. There are many forums about these already and I read those, but they still don't solve my issue completely...
1. There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "XXX", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
2. Referenced assembly 'XXX' targets a different processor than the application.
The reason why these appear in our case is clear. Our solution is compiled as AnyCPU and we want to keep it this way, as we do not want to compile it twice (once as x86 and second as x64). However, we use external DLL which is either x86 or x64 (it is not delivered as AnyCPU).
We develop the application on 64bit windows, so we use the x64 DLL version as reference in the visual studio during development. When we deliver the application to end-users, the installer is customized to copy the proper DLL based on the platform of the target system, e.g. when it is installed on 64bit windows, it copies the x64 DLL version and when it is installed on 32bit windows, it copies the x86 DLL version. Therefore, we know that everything is finally ok, and we can ignore those messages. And therefore, I just want to make them disappear:-)
The first warning can be supressed by the following tag in the project file:
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
But I did not find anywhere how to get rid of the other message? Is this possible as well?
I know that this is just small issue and I can live with that. However, there is something like "Warning Free Build Initiative" going on in my company, so I'd like to get rid of all warnings we have.
Thank you in advance for any hints,
Tomas
Related
I've installed several packages in a Unity (2020) app I'm building. Namely: World Locking Tools, MRTK, PUN2. World Locking Tools provides some examples that are built with assemblies defining scripting symbols that any derived files I want to build would need access to. I'd like to create my own version of certain files from one of these examples. To do this and have access to the scripting symbols in one of those examples, I created an assembly reference to reference the assembly for that example code within World Locking Tools package installed in my project space. In so doing, I kept running into the common "...not found, are you missing an assembly reference" issue, which ultimately led me to creating assembly references for many of the assemblies provided by the various packages I needed to use (not just the particular example code I initially wanted to modify). Once my project finally built successfully in unity, I then tried to upload to a Hololens 2 headset in Visual Studio. This provided the error in the title of this post. Coincidentally, the app also appears to fail to start on the headset. Before I tried to alter my codebase with modified versions of files from that World Locking Tools example and with assembly references, the code would successfully build in Unity and successfully deploy to the Hololens 2 headset.
Does the behavior and missing .pdb error I describe mean that I'm missing assembly references for yet other packages even though Unity successfully builds the project?
This is my first foray into using assemblies so be please be gentle :)
For the .pdb message, that one is ignorable since will not have that symbol available. However, the app not starting is definitely likely due to a missing component or loading issue. When ran in debugger, may get a better idea on what is missing or from a debugger log in Unity.
I'm updating projects in a .NET Framework solution containing a DLL and an EXE to target .NET 5.0. Every call from the from the EXE which touches the DLL is marked with the warning:
Warning CA1416 'MyDllClass.MyProperty<int>(ref int, int, string)' is supported on 'Windows' 7.0 and later
The suggested actions from Microsoft basically amount to either adding cruft to every call or just giving up and suppressing the warnings. Logically, I expected to be able to mark my EXE to declare that it was targeting Windows 7.0 or higher, so that it would give an exception if anyone tried to run it elsewhere, but the compiler could assume this was the baseline for all API calls. Two things I tried, neither of which helped:
Attempt 1
<SupportedOSPlatformVersion>7.0</SupportedOSPlatformVersion>
Attempt 2
<TargetFramework>net5.0-windows7.0</TargetFramework>
What is the elegant way to address this situation? The fact that I'm in control of both projects seems like the best-case scenario.
From EXE Project:
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
From DLL Project:
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
Thanks to a comment by Hans Passant, I tried removing this from my EXE project:
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
I also had to remove the AssemblyInfo.cs due to auto-generated fields conflicting with fields defined in there. After that, all good, no warnings. I presume the compiler is generating whatever fields it needs to keep itself happy.
I also guess that this would not be an issue on a green-field project and that I only ended up with that element somewhere in the process of migrating the application.
An mixed-mode C++ application is built using VS2012, it references the managed DLL Noesis.Javascript.dll (which I believe was built with VS2010) which in turn links at runtime with msvcr100.dll.
I have observed a crash which seems to show the code within the Noesis.Javascript.dll calling library functions from VS2012's msvcr110.dll.
Is it possible to run a single process using two different versions of the C++ runtime libraries or is what happening here the likely cause of the problem? What is the alternative?
As mentioned for instance in this answer, it is practically impossible to combine these binaries. The crash is probably caused by the incompatiblity.
You could try the following: Project Properties -> General -> Platform Toolset: Visual Studio 2010 (v100).
It is possible to use both runtime DLLs in the same process, but to do so safely requires great care to ensure that no objects from one are used in the other.
I have a simple .exe written in C++ (built with Visual Studio 2005) that tests some hardware using a supplied API. It works fine on the Windows 7 machine I built it on, but when I copy it to another (Windows 7) machine and run it (from the command-line) I get:
The application has failed to start
because its side-by-side configuration
is incorrect. Please see the
application event log or use the
command-line sxstrace.exe tool for
more detail.
What is "side-by-side configuration"?
I ran sxstrace.exe and read the usage info. It appears I would need to instrument my exe to generate a log file for sxstrace.exe to be useful?
I imagine the problem is my exe requires DLLs that either don't exist on the other machine, or are the wrong version. How do I find out what DLLs my exe uses, and what versions it links to on my machine (where it works)? Any other advice on copying it to another machine and getting it running? Would more information help?
mfawzymkh's answer to the "application has failed to start because the side by side configauration is incorrect" question (linked to in the question spirulence linked to in his answer to this question) appears to apply to this question also. mfawzymkh writes:
You can resolve this issue by either
one of these 1- Install VC8 Debug CRT
2- Build you app as statically linked
And mfawzymkh's comment on that same answer explains how to build as statically linked:
when you build it in VS, go to
projects->settings->C/C++->Code
Generation and choose Runtime Lib
options to be /MTd instead of /MDd
I did that and the side-by-side configuration message is gone. (And after installing something else for the DLL I was using, my EXE works.)
For what it's worth, I encountered the same issue. In the Event Viewer I had an error message that read:
Activation context generation failed for "C:\\MyExe.exe".Error in manifest or policy file "C:\\MyExe.exe.Config" on line 12. Invalid Xml syntax.
Sure enough, I'd changed a connection string and left out the closing quote. Added that back in and it solved the issue.
"when you build it in VS, go to projects->settings->C/C++->Code Generation and choose Runtime Lib options to be /MTd instead of /MDd" worked for me, although I was interested in the Release version instead of the Debug version.
Microsofto says:
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
/MD
Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib.
Are you suffering from the same issue as this guy? Side-by-side assemblies, Windows 7, and Visual Studio 2005
We have recently decided to start shipping the versions of some of the DLL files that a product requires with the product itself.
This is to guard against the situation where (for example) the MVC DLL file is updated on the server to which the software is deployed and the product fails to work as it was written against the now previous version of the DLL.
If the MVC DLL file of the specific version is included in the product and "locally" referenced this prevents this problem from happening. (In an ideal world every product which will be installed onto the destination server would be updated to the most recent version but this is not always practical)
My concern and question is whether this is going to give a false sense of security or not actually cope with the problem in the following situation: if Version 1.0 of the MVC DLL file is relying on method X of standard Microsoft DLL library Y and this DLL file Y is updated we will be in the same situation of having a broken product?
Assuming you meant the MSVC (Microsoft Visual C++) DLLs, the correct solution is to use an application manifest. The MSVC DLLs support Side by Side installation (SxS). This means that a new version of those DLLs does not replace an old version. Your application manifest tells Windows which DLL version(s) you want.
I don't know about MVC specifically, but you have a bigger problem if the conflicting version of a dependency dll is installed to the GAC on your target machine, as it will be used in preference to the local file.
Depending on how big it would make your final product, consider statically linking your program. This will prevent the much dreaded DLL hell since you wont have to give DLLs out.