At trying to run a test application i obtain the following error twice:
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. TestMobile.Core
mismatch MSIL x86
I have .NET Framework installed, as well as windows 8 SDK tools and using MultilingualAppToolKit.
I already have verified the configuration manager and everything seems to be fine. Platform target, targeting "Any CPU"
Copying over my existing version of .NET Portable Library Reference Assemblies fixed the issue for me.
I encountered this problem after installing a patch to Visual Studio 2015 Update 3, read vvolkgang's response and initially discounted it because I already had folders within C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable, and the dates of those folders were later than those contained within the reference assemblies archive I had downloaded. What I should have done was to check the right part of the folder hierarchy. Take a look at your project file; in my case I had these settings:
<TargetFrameworkProfile>Profile49</TargetFrameworkProfile>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
If those are your settings, you need to check the contents of C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.5\Profile\Profile49. If you're using a different profile or targeting a different version of the framework, adjust the path accordingly. When I checked that folder, I discovered that I had lots of XML files but no DLLs; copying the files from Microsoft .NET Portable Library Reference Assemblies 4.6 and choosing not to replace any files that already existed fixed my build issues.
Had this problem after installing Visual Studio 2015 Update 2. Try this, the first one solved my problem:
Install Portable Class Libraries v4.6
Download Install the Portable Class Libraries v4.6. If you install this it puts a .zip file into the directory:
"C:\Program Files (x86)\Microsoft .NET Portable Library Reference Assemblies 4.6"
Unpack and copy the contents into "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\"
Install the PCL Tools
Download Portable Class Library Tools
Install by running PortableLibraryTools.exe /buildmachine
Source: Matt Ward # https://forums.xamarin.com/discussion/comment/80535/#Comment_80535
I finnally was able to build my project without this filthy error. It seems that i needed to install PortableLibraryTools from VS2010. It worked after that.
Reference: http://forums.xamarin.com/discussion/25538/xamarin-xaml-example-problem-using-pcl
If you are on a build Server and getting this Error/Warning , just install MSBuild 17 with its optional installations which contains all the SDKs and Portable libraries.
Related
I'm about to distribute a fixed version of WebView2 with my project. According to the Microsoft guide "Details about the Fixed Version runtime distribution mode" after downloading [1] and decompressing [2] the package I have to include binaries into my project [3] and indicate path the fixed version binaries when creating WebView2 environment [4].
The decompressed folder contains 169 files. Which files should I include and how do I include them?
I'm using .Net Framework 4.8. Currently I get following error in Visual Studio: "The type or namespace name 'Web' does not exist in the namespace 'Microsoft'"
Generally we recommend using the Evergreen distribution model. It will save disk space on the end user's machine since its shared with other apps using evergreen WebView2 and its automatically kept up to date for you, unlike Fixed Version. You can read more about the pros and cons of both approaches.
If Fixed Version makes the most sense for your application, you need to ensure that all of the files in the cab package are on the disk somewhere for your app to reference them. If you are using something to build an installer, it should let you reference the folder of the Fixed Version files to have placed in the install path of your application.
The error about Web does not exist in Microsoft sounds like a missing reference to the WebView2 nuget package. Make sure you are also installing the WebView2 assemblies and loader files as described on Files to Ship With the App. These are SDK files that must be included in addition to the Fixed Version WebView2 Runtime files described above.
\<myApp>
\Microsoft.Web.WebView2.Core.dll
\Microsoft.Web.WebView2.Winforms.dll
\Microsoft.Web.WebView2.WPF.dll
\runtimes
\win-arm64\native\WebView2Loader.dll (arm64)
\win-x64\native\WebView2Loader.dll (x64)
\win-x86\native\WebView2Loader.dll (x86)
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 am pulling this project from a git repository that depends on Microsoft.SqlServer.Types which should install msvce120.dll and SqlServerSpatial140.dll. But for some reason it does not install them. They appear in the solution explorer as seen on the image. But the files are not there in windows explorer.
The project was cloned from a git repository. As soon as I tried to build the project, VS started downloading the necessary nuget packages, but this files fail to download. The original repository has these files marked as git ignored.
Where am I going wrong here? I could simply copy and paste the dlls from the original repository but I want to understand why they are not being downloaded or installed.
If you installed this package into a project using the <PackageReference> style of packages (typically found in .Net Standard / .Net Core applications), then the files are not added because there is a lack of support for the install / uninstall scripts used for this function.
Specifically, when installing / restoring this package, there is an install.ps1 script that is supposed to be ran which creates the folders and places the dll's you're referencing into these folders. Again, there is no support for this functionality in the <PackageReference> style of packaging.
This is juxtapose to the packaging style that uses Packages.config which DOES have support for install / uninstall scripts.
You can read more about this here: https://github.com/NuGet/Home/issues/6330
Edit: After submitting this post I identified the real issue: MSBuild/TFSBuild does not deploy .dll 'CopyLocal=true' files if they are found in the GAC. In this case the "System.net.http.formatting" dll is in the GAC on the build server. Look here and here
After an upgrade from TFS 2012 to 2015, the build agent no longer copies the following DLLs to the drop locations. How can I identify why the build agent is not copying those files?
system.net.http.formatting, System.Web.Http.dll or System.Web.Http.WebHost.dll
Detail
We have solution with MVC projects that reference the above dlls.
The .csproj files use a hint path to reference the files in the solution /packages/... directory. I have confirmed the path is a valid: the solution has a packages directory.
Before the upgrade to TFS 2015, when building the solution, the above files are copied to the drop location. However they are not after the upgrade.
The build does not fail, however after the TFS 2015 update the target web server throws a 'file not found' error. (MVC is not and cannot be installed on the target web server)
The build utilizes a 2012 XAML Build Definition
Looking at the build log files, both reference the .dll files
CSC.exe ...
/reference:D:\B\15...\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll
The build logs shows that only the version build by TFS 2012 copies the .dll file to the drop location. The 2015 build log does not have a line similar to the following:
Copying file from "D:..\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll" to "D:..\BIN\EG.WS.EZScan.Web.Intranet\System.Net.Http.Formatting.dll
The build server was not changed during the upgrade other than the re-install of the build agent. The server was not rebuilt. No components were removed or added.
The project did not update to a newer version of MVC. The projects reference version 4.0.0.0. The GACed files on the build server is version 4.0.0.0 (file version 4.0.20710.0)
What else should I look at.
Since you have upgraded to TFS 2015, it's suggested to use the new build system which is completely different from XAML build. Check: https://www.visualstudio.com/en-us/docs/build/overview
It seems you are still checking in the referenced dlls to TFS, which is not suggested. Instead, we suggest restore the packages via a package manager such as NuGet. Check "Migrating to automatic restore" at website https://docs.nuget.org/ndocs/consume-packages/package-restore#msbuild-integrated-restore
If you start to use new build system, you can simply include the Restore NuGet Packages task in the definition before any build task. Detailed information of Nuget Package Restore, please check https://docs.nuget.org/ndocs/consume-packages/package-restore
I'm trying to build my solution using TeamCity / MSBuild.
It's a WebAPI project which shares some entities in a PCL with a mobile client.
I see there are a few caveats around getting the PCL reference libraries installed on a buildserver, which I think I've sorted
(Building Portable Class Library Project in build server fails)
However, I'm getting an error during the build of the portable class library as follows:
[11:20:49][Doctrina.Pcl.Entities\Doctrina.Pcl.Entities.csproj] _GetSdkToolPaths
[11:20:49][_GetSdkToolPaths] GetSdkPropertyValue
*[11:20:49][GetSdkPropertyValue] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(975, 5): error APPX3212: SDK root folder for 'Portable 7.0' cannot be located. See http://go.microsoft.com/fwlink/?prd=12560&pver=1.0&plcid=0x409&ar=MSDN&sar=PlatformMultiTargeting&o1=Portable&o2=7.0 for more information.*
The "help" link doesn't go anywhere useful and it seems to be very google-resistant in terms of finding any resolution.
I don't have Visual Studio 2015 installed on the build-server at all, but I have installed PortableClassLibrary tools, copied the reference directory from my local PC over, etc, as per the other related SO question.
Help please?
I encountered this error when attempting to build portable projects targeting .NET Standard.
I managed to resolve it without installing Visual Studio on my build server, by copying from a machine that does have Visual Studio installed:
C:\Program Files (x86)\Microsoft SDKs\Portable\v14.0
C:\Program Files (x86)\MSBuild\Microsoft\Portable
C:\Program Files (x86)\ReferenceAssemblies\Microsoft\Framework.NETPortable
I later attempted to build a WebApi project targeting .NET Core (this was an xproj file) and as soon as I added the XProj file to my solution, I had to also copy:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet.Web
That got me a bit further but it also caused other projects to stop building properly (that were working fine without the XProj file in the solution). One thing I noticed, the NuGet tooling for .NET Core does not support authenticated NuGet feeds, so I had to enable anonymous access on my feed. But now my .NET Standard project now fails with error MSB4057: The target "_GenerateDependencyFragmentJson" does not exist in the project.
I've yet to get around to diagnosing this, but I hope the above information helps someone. If you're not using xproj files and just trying to use .NET Standard projects, the above should be all you need to build without installing Visual Studio.
Just a side note, I tried really hard to avoid having to copy these files by first trying to install Microsoft Build Tools 2015 Update 3, hoping it would put the required files in place, but it did not sadly. I'm pinning my hopes on the next version of MSBuild that is being used in VS15, and hoping that it's build tools package will have everything required to build this stuff when it comes out, as it doesn't seem like they are updating the 2015 Build Tools with this support.