My solution contains a lot of project, when switching from AnyCPU(32bit) to x64 I get alot of Metadata file X could not be found?
To build all projects in x64 I use the Configuration Manager where I set it to release and x64.
Sometimes the trouble is caused by references between projects where the project dependencies are not updated. You can confirm them under Project -> Project Dependencies for each project giving trouble.
Related
In Visual Studio 2017 I created a Stand-Alone Code Analysis Tool project targeting 4.6.2. I used the templated code as-is except that I specified the .sln file for the workspace.OpenSolutionAsync() call.
The solution I am attempting to compile with this Roslyn method contains both projects where Platform=Any CPU, and projects where Platform=x64. The solution compiles fine in VS2017 when set to Mixed Platforms.
However, the OpenSolutionAsync() call generates several of these compile errors:
Msbuild failed when processing the file 'C:\MyProj.csproj' with message: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets: (2110, 5): There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\MyUnmanagedLibrary.dll", "x86". 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.
Why is it complaining about x86 when the MyUnmanagedLibrary project has been set to build using Platform=x64 in the Configuration Manager? How do I resolve this? This code was working fine one day ago and to the best of my knowledge nothing has changed except that I copied code to a different directory on my PC.
The cause of this behavior was that some of my projects had an output path of bin\Debug\, and others had an output path of bin\x64\Debug. However, the build process performed when you call OpenSolutionAsync() appears to assume bin\Debug. It was finding old x86 versions of DLLs in bin\Debug\ folders instead of looking at the DLLs in bin\64\Debug\ folders. Once I changed all the projects' output paths to bin\Debug\, the OpenSolutionAsync() process worked fine.
I'm using OpenCvSharp with visual studio 2013. I've installed it through Nuget and it is working fine.
But when I deploy the application it has a DLL directory that has 128M. 128M for x86 and 128M for 64 indeed.
I'm using basically the functions from HighGui and Core. When I remove the DLLs, OpenCvSharp throws an exception when loaded.
I've tried recompile OpenCvSharp without success (this is another question) and even Recompile OpenCV to get smaller DLLs.
Is there any way of loading only the needed DLLs and point out which one can be removed?
The size of your deployment sounds quite large...
When I create a test project with Nuget package OpenCvSharp-AnyCPU 2.4.10 I get:
1.22MB for the net40 assemblies
32MB for the x64 dlls
29MB for the x86 dlls
OpenCvSharp loads the native dlls on demand (i.e. when the C# code needs the native code) so you could remove dlls which your code never uses, but you'd have to check the source or find this out by trial and error.
By default your C# app will build targeting Any CPU which means both sets of dlls are needed, but you could set Platform target: x86 in build properties and just not deploy the x64 dlls.
I have three projects, ProjectA (exe), ProjectB (exe) and ProjectD (class library)
Project A references the System.Data.OracleClient.dll and ProjectD. Project B just references ProjectD. The 32-bit client version of oracle is installed and therefore ProjectA has to be a 32-bit application. Project B can be built as a 64-bit application.
Project A build settings:
Platform: Active (x86)
Platform target: x86
Project B build settings:
Platform: Active (Any CPU)
Platform target: Any CPU
My questions are what should the build settings be for ProjectD (the class library) and when ProjectA and ProjectB get built does it build ProjectD differently? A deeper explanation of the CLR would be great in terms of communications of the projects.
ProjectA and ProjectB are to be used on 64-bit Windows Server 2008. No installation, just standalone exe's.
Only the Platform target setting for the EXE project matters. That's the assembly that gets loaded first and determines the bitness of the entire process.
A DLL doesn't get a choice, it must be compatible with whatever was selected by the EXE project. Picking AnyCPU for a DLL project is therefore almost always the correct selection.
There are just a few cases where you'd use an explicit setting. You'd only do so if you know that the class library has a dependency on some kind of native code, like the Oracle provider, and that trying to run that native code in the wrong bitness produces a completely inscrutable exception. You can avoid that exception and get a (slightly) better one by picking the Platform target for the DLL, the program will fail with a BadImageFormatException early when it tries to load the assembly. Albeit that this exception isn't exactly a very informative one either. Some odds that an admin is going to try to reinstall the DLL a couple of times before deciding that the real problem is elsewhere.
So basic ground rules: pick x86 for the EXE project, AnyCPU for all other class library projects, a nastygram to Oracle for doing nothing to make this easy.
My questions are what should the build settings be for ProjectD (the
class library) and when ProjectA and ProjectB get built does it build
ProjectD differently? A deeper explanation of the CLR would be great
in terms of communications of the projects.
Just use Any CPU for your lib. It'll build a unique assembly that can be executed in both 32-bit en 64-bit environments.
Technically, the just in time compilation with either produce 32-bit code or 64-bit code at runtime.
I develop on a pretty big windows forms .net (C#) application with several assemblys. Originally each assembly was build for the Target Platfom "Any CPU".
Due to a problem with Crystal Reports on x64 machines we had to build the whole project for x86 target platform. I startet rebuilding some of our Projects for x86 and it worked just fine.
But with one I have the problem that when I try to use it as a reference in another Assembly, the other one won't load it giving following Error:
Could not load file or assembly #MyAssembly# or one of its dependencies. An attempt was made to load a program with an incorrect format.
When playing Around with Crystal in a sample project with more than one assembly I found out that this error occurs when the Projects are build for different target platforms. But this isn't the case here. I build every Project for X86 and just can't figure out where the problem is here.
You can try, to build your MainProject (Executable) with target platform "x86" or "x64", an all other projects you set to "Any CPU".
I have a third-party project type in Visual Studio which for some reason only supports the .NET Platform configuration for the build, for all other (standard C#) projects in the solution I only have AnyCPU. Unfortunately, ever since upgrading to VS 2010 it produces following error when built :
Error 39 The OutputPath property is
not set for project
'ReferencedBusinessProject.csproj'.
Please check to make sure that you
have specified a valid combination of
Configuration and Platform for this
project. Configuration='Debug'
Platform='.NET'. This error may also
appear if some other project is trying
to follow a project-to-project
reference to this project, this
project has been unloaded or is not
included in the solution, and the
referencing project does not build
using the same or an equivalent
Configuration or
Platform. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 483 10 CustomTypeProject
It's pretty much descriptive in what is missing but I haven't found any way to fix it so far. Do you have any idea how this can be resolved or what can be the problem ?
The .Net Platform must have been created for the project before you received it for transparency reasons check the project settings and if it's building any cpu then fix the project configuration. (Standards are AnyCPU, x86, x64, win32) etc...
I would suggest you right click on the ".sln" file and in configuration manager set the properties of what you would like build when you call a platform. I.e.
This sample is best served with a configuration called "Mixed Platforms"
csproj1 platform=AnyCPU configuration=debug build checkbox (checked)
csproj2 platform=.net configuration=debug build checkbox (checked)
This will allow you to build with msbuild
The call would be
msbuild my.sln /p:configuration="Debug" /p:platform="Mixed Platforms"
Both projects will build.