I updated my VS 2015 recently with the latest patch version and since then I get this error:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscorlib.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.
Output:
Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Rebuild All started: Project: MoneyFox.Shared, Configuration: Debug Any CPU ------
1>C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\MoneyFox.Shared\MoneyFox.Shared.csproj(333,3): warning MSB4011: "C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\packages\Fody.1.29.4\build\portable-net+sl+win+wpa+wp\Fody.targets" cannot be imported again. It was already imported at "C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\MoneyFox.Shared\MoneyFox.Shared.csproj (325,3)". This is most likely a build authoring error. This subsequent import will be ignored.
1>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): error MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\\mscorlib.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.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The only other entry is a warning who should be the reason.
Strange is, that the project who the error occurs doesn't have the mscorlib referenced.
The error occurs in the PCL Shared Library part who is referenced by the platform specific projects. Therefore these can't build aswell.
My current build configuration is as follows:
The shared project in special:
Repository: https://github.com/NPadrutt/MoneyFox.Windows/tree/AndroidBackgroundService
I tried to repair vs but that didn't change something, as does reinstall it completly.
Funny is, that I can build it on a windows 7 pc (but get runtime error instead).
Also I can't build my master branch anymore who was buildable some days ago.
What's wrong here!?
EDIT: I created a new portable class library and unloaded all other projects.. I get the same error, also when I create a new project with just a portable class library in it. So it seems there is something pretty wrong with my current installation...
I found a solution for the problem. It seems that some of the .net profile got corrupt. But they didn't get repaired with a reinstall or repair of VS. So, therefore I deleted the Files and folders under the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable
Then I repaired VS and it worked again..
I wouldn't think that this has to do with applying the latest patch to Visual Studio 2015.
We see this warning when we have one project that is built for x86 referencing another build for AnyCPU. This can be fixed in the Project Property page (right-click the project and click Properties). In the Build tap you can set Platform target. I would suggest that you set the configuration combo box in the top of the property window to All configurations before updating this to get it set consistently.
You can also correct this by unloading the project and editing it manually. Look for the AnyCPU property and insure that it is set in a property group without conditions or in all property groups for each configuration condition.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<OutputPath>bin\Debug\</OutputPath>
...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<OutputPath>bin\Release\</OutputPath>
...
</PropertyGroup>
Related
INTRODUCTION
I am building a class library which could be used by some legacy applications targetting .Net Framework 4.0 and new applications targetting .Net Framework 4.6.1
I am adding some database/Hibernate new code in the class library that requires .Net Framework 4.6.1. This new code is incompatible with .Net Framework 4.0 because the nuGet package FluentNHibernate 3.1.0 requires .Net Framework 4.6.1 and up. And legacy application does not require this functionnality.
WHAT I AM TRYING TO ACHIEVE
I am attempting to conditionnaly build the class library so one code base and the master git branch can be used to build a version compatible for either one or the other application.
So far, I have been able to:
Define a constant indicating the target framework (FWK40)
for use within .cs code to adjust code to target framework
Conditionally define the targetted framework (TargetFrameworkVersion)
Exclude files from build when not under the right TargetFrameworkVersion
Here is what the .CSPROJ looks so far (emphasis for the relevant adjustments):
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug.Net40|AnyCPU'">
<!-- Set target framework here -->
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\Debug.Net40\</OutputPath>
<!-- Define Build-time constant here -->
<DefineConstants Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" >FWK40</DefineConstants>
</PropertyGroup>
<ItemGroup>
<-- Conditionally include .cs files here -->
<Compile Include="Database\GeneralSQL.cs" Condition="'$(TargetFrameworkVersion)' != 'v4.0'" />
<Compile Include="Database\NamingStrategy.cs" Condition="'$(TargetFrameworkVersion)' != 'v4.0'" />
<ItemGroup>
<ItemGroup>
<-- In THEORY conditionally include PackageReference here -->
<PackageReference Include="FluentNHibernate" Condition="'$(TargetFramework)' != 'net40'" >
<Version>3.1.0</Version>
</PackageReference>
</ItemGroup>
THE RESULT SO FAR
What is happenning, is I am getting a nuGet error saying:
NU1202: Package FluentNHibernate 3.1.0 is not compatible with net40 (.NETFramework,Version=v4.0). Package FluentNHibernate 3.1.0 supports:
Failed to restore C:\_projets\repos\TestSolution\TestLibrary\TestLibrary.csproj (in 19 ms).
NuGet package restore failed. Please see Error List window for detailed warnings and errors.
Not withstanding this error, the assemblies all are generated properly, the DLL Class Library itself, as well as an EXE Console application using that class library AND so far they run properly.
THE PROBLEM
I haven't been able to conditionnaly include nuGet a PackageReference.
AND The nuGet error still causes MSBuild.exe to fail, which prevents the CI/CD pipeline to work properly..
WHAT I HAVE TRIED
I have tried many many ways to get rid of nuget NU1202 error message.
#1 I have tried initially with other conditions based on $(TargetFrameworkVersion) which works througout the .csproj but to no avail.
#2 According to official documentation, nuGet ReferencePackage only supports conditions based on $(TargetFramework) adding-a-packagereference-condition as shown in the sample .csproj above. YET THIS STILL DOES NOT WORK.
I haven't been able to figure out so far what exactly the Property TargetFramework looks like. I ran MSBUILD.EXE in Verbosity level diagnostics, which dumps all the Properties, but TargetFramework wasn't listed (while others were)
I have tried to "reverse" the condition == 'net461' so that if the expected value is incorrect, it won't be included and the error would disappear => no effect, errors still there
#3 I have tried to define myself the TargetFramework property
<!-- Set target framework here -->
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<TargetFramework>net40</TargetFramework>
The outcome would be much worse!
Visual Studio did not like it, the "Configuration Manager" broke down
it would not allow to set a specific Configuration for a project.
changing from Debug.Net40 to any other configuration (or loading the project) would show a nasty error message
Current solution contains incorrect configuration mappings. It may cause projects to not work properly
And the csproj was definitely not loaded properly either and project would be skip the build step.
WHERE I AM AT NOW
I am really stuck! Can't seem to find a way to make this work.
I would hate to have to have a branch master40 and a branch master just to handle this.
I would hate to have to have two csproj different files, unless I can somehow manage to share/include one into the other AND Visual Studio would not complain
The really really right thing would be to make the conditions on the ReferencePackage to actually work as intended.
What you want is multi-targeting.
The documentation you link seems to be only applicable for SDK-style projects.
AFAIK, multi-targeting is not available with the legacy-style project format.
I suggest migrating to the SDK-style project format.
A lot of things are much simpler there, not to mention better documented.
You can use a tool to do this, like hvanbakel/CsprojToVs2017 or dotnet/try-convert. Don't be fooled by its name and wrong usage of terminology.
(since this is also mixed up on SO all the time: yes, you can use the SDK-style format with .NET Framework TFMs; SDK-style has nothing to do with either TFM or Visual Studio version, but only with minimum required MSBuild version).
Once you have done that for your particular project, the documentation for multi-targeting applies and you can use Condition on $(TargetFramework) just like you have already done, in both your PackageReference and the Compile item group and pretty much anywhere you want.
There are many other (older) MSB3270 mismatch errors questions posted on SO, but many of them are a decade old and for generations before NET 5. I have a set of NET 5 solutions that are all set to Debug AnyCPU in the Build / Configuration Manager. Yet I still get the warning message about mismatched architectures.
Here is my MSBuild command line:
%msbdir%\msbuild -nologo -m -V:q "%1" /t:Clean;Restore;Rebuild;Publish
/p:PublishProtocol=FileSystem /p:PublishDir=%coredir% /p:RuntimeIdentifier=win-x64
Here is the output:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin
Microsoft.Common.CurrentVersion.targets(2203,5):
warning MSB3270: There was a mismatch between the processor architecture of the project
being built "MSIL" and the processor architecture of the reference "HsLogger", "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. [c:\dev\HsUtils.csproj]
Publish Ok - hsutils\hsutils.sln to c:\dev\holding\core.plt
I am certain that everything is set to Debug AnyCPU, so why is MSBuild protesting? I read somewhere else that AnyCPU is pretty meaningless and that I should specify x64 or x32 (or both) in my build configurations. I have net5.0-windows7.0 for a TargetFramework in the project files, but nothing else (no RunTimeIdentifier settings).
I wonder if the msbuild parameter /p:RuntimeIdentifer=win-x64 has something to do with it, but I don't know enough for sure. Should I be explicitly adding runtime identifiers to all my project files?
Is explicitly picking x64 the way out of these warnings, or should I just suppress them in my MsBuild command-line options? (Suppression seems like a bad move because it's a pretty serious issue if there is a true mismatch.) Thank you
UPDATE
In case it helps, my project files all look like this:
<PropertyGroup>
<TargetFramework>net5.0-windows7.0</TargetFramework>
<UseWindowsForms>true</UseWindowsForms>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<SelfContained>false</SelfContained>
<PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>
So,
The company has a SonarQube key for each individual project. So, we got a Common.dll project, and a Network.dll project, and a MyProject.exe project all maintained in SonarQube as individual projects.
However, in my Visual Studio i have one solution with all three projects. How can I "bind" each project to SonarQube for all of them, so that the binding is between Common.dll and Common.dll, not MyProject.Exe for all three.
(if that makes sense). I want the connected mode binding to be individual to project, not one project for the entire solution.
Thanks
Jaeden "Sifo Dyas" al'Raec Ruiner
This is not supported by SonarLint and there is no plan for short-term on this.
You may exclude common projects from analysis. A PropertyGroup that I shared below, conditionally excludes the library from the analysis scope based on a solution's name (.NET csproj file):
<PropertyGroup>
<SonarQubeExclude Condition=" $(SolutionName) == 'Solution1' ">true</SonarQubeExclude>
</PropertyGroup>
I have projects with localized resources and x64 native dependencies. Is there any way to build them without warnings?
If I set the target platform to AnyCPU I get this warning because of the native references:
warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Native64", "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.
OK fair enough, but:
If I set the target platform to x64 I get this warning, because localized resources automatically create a satellite assembly with the wrong target architecture:
ALINK : warning AL1073: Referenced assembly 'mscorlib.dll' targets a different processor
Microsoft says it's a bug, but they wont fix it.
So now what?
Here is a workaround:
The issue can be avoided by using the AL.EXE that matches the platform (or bitness) you are attempting to build. That is, you'll see that when you are building x64, that it is trying to use AL.EXE at a path similar to
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools
If you can get it to use the x64 version of AL.exe, the issue will go away. That is, use the AL.EXE at a path similar to:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64
Msbuild finds this path by using its TargetFrameworkSDKToolsDirectory. Thus, using the assumption that this directory is the correct directory when building x86, the workaround below essentially appends the x64 sub directory on to the path when building x64 and leaves it as is otherwise:
Create an MsBuildAL1073WarningWorkaround.targets file (name doesn't matter) and add it to the project. It has the following contents:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory Condition=" '$(PlatformTarget)' == 'x64'">$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
</PropertyGroup>
</Project>
Edit the .csproj file to import this file near the end of the file (where you'll see the comment that says "To modify your build process...":
<Import Project="MsBuildAL1073WarningWorkaround.targets" />
<!-- To modify your build process... -->
I have a need to build a website and several DLLs that it references in an x86 configuration. To date we have been using Web Deployment Projects to create Zip files of the resultant site and all it's required files. We need to continue to use WDPs however, they seem to have problems with the x86 build configuration.
In my project, when I build the solution in Release/x86 I get the following error.
Description File Line Column Project
Error 80 Could not load type 'WwwRooot.Default'. /WwwRooot.csproj/Default.aspx 1 1 WwwRooot.csproj_deploy
There are no build errors or warnings from the web application or any of the referenced class libraries.
I thought this might be something specific to the project I'm working on so to prove myself wrong I created a solution containing a Web Application (c#). I then used the Configuration Manager to create the x86 configuration by copying the Any CPU config. I checked the properties page an made sure the new config was set to build to x86, and it was. I built the solution without error.
Next I right clicked the Web App and added a WDP from the context menu.
Right clicked on the WDP and edited the project file. At this point I changed any references for AnyCPU to x86 so that the WDP has conditions of x86 build.
I rebuilt the solution in Release/x86 and everything builds fine.
Next I add a Class Library, use Configuration Manager to create an x86 config for this library, add a reference to the web app for the library and then rebuild all in Release/x86 and I receive the same error as detailed above.
Are WDPs compatible with x86 build?
If I remove the Class Library (and the reference) the solution (including the WDP) builds fine.
I am using Visual Studio 2008 SP1, with the appropriate WDPs installed, on 64Bit Windows 7 Pro.
Out of the box, Web Deployment Projects (WDP) don't work with x86 or x64 build configurations. This is because a Web Application built under one of these configurations outputs the resultant assemblies in a different place and the WDP doesn't know to look there for the DLLs.
There are a few things you'll need to do to get the WDP working with your x86 configuration.
Firstly, your WDP probably doesn't have an x86 configuration, you'll need to create one. Edit the deployment project using the XML editor in Visual Studio (or any text editor), near the top of the file will see a <propertyGroup> tag (usually the second one) with a condition Debug|AnyCPU like so:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>.\Debug</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
</PropertyGroup>
Duplicate this whole tag and change the configuration to be Debug|x84:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>.\Debug</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
</PropertyGroup>
Now save the file and open the configuration manager (Build menu > Configuration manager) and check your deployment project now has an x86 configuration.
Now edit the Web Application Project file using your text editor and locate the outputPath element within the Debug|x86 configuration. It should have a value of Bin\x86\Debug. This needs changing to Bin:
<!-- Before -->
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<OutputPath>Bin\x86\Debug\</OutputPath>
<!-- After -->
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
<OutputPath>Bin\</OutputPath>
Save, close and reload you Web Application Project. We've now instructed the Web Application to put it's DLLs where the WDP expects to find them.
Set your build configuration to x86 and build the project.
Rinse and repeat for Release and any other build configurations you might have.
Try this
Put this command in post compilation events of your web project
xcopy "$(TargetDir)*.*" "$(TargetDir)..\..\" /Y
This command wil copy files from bin\x86\Debug to bin
It will work with Release configuration