We Keep Coding

Unhandled Exception. Could not file or assembly "System Memory)

After I included some .cs files from another project in my application when I publish my app and run it I get the following error.
My application is a windows form and the files I included are some kind of file parser in order to process a certain file type.
I have tried many times to rebuild and reload the project but the result is still the same. The target framework is .NET 4.8.
Does anybody has any idea on how to solve this issue?

That's because most probably, the code you inserted requires the presence of that dependency.
However, System.Memory is not part of the default framework, it's current version is 4.5.4 and it can be found on nuget.
If you use Visual Studio, you can conveniently add it to your Solution by using the Nuget Package Manager
You need to handle that dependency, either by installing the nuget package for your solution, or by directly downloading and providing the dll and its dependencies from the nuget site (not recommended).

error APPX3212: SDK root folder for 'Portable 7.0' cannot be located

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.

Processor architecture mismatch building error

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.

Azure package contains incorrect DLL

In my web and worker roles, I am referencing an alternative version of a core framework DLL. The file is marked Copy Local. Visual Studio shows the correct version in as a project reference. When compiling the project, the bin directory also contains the correct version.
However, when I ask Visual Studio to create an Azure package, the package (and the csx folder created during packaging) contains the wrong (original) DLL for the Worker role only. The Web role has the correct DLL. This does not occur if I manually use cspack, but that's not really a desirable way to package.
What could cause Visual Studio to compile with the correct reference DLL but bundle the wrong one?
Additional info:
When I run msbuild to do the packaging instead of Visual Studio, I see the following two lines:
Copying file from "C:\Users\bytenik\Dropbox\Treadmarks\lib\EntityFramework\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
Copying file from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
So, it seems to copy my reference, and then copy over it with the system reference.
Note: I'm well aware that the entire concept of replacing a .NET CLR DLL is a huge hack. When .NET 4.5 comes out supporting the feature I need, this will all be stripped out. In the meantime, I need to be able to continue development.
This is a replacement to question "Azure References Incorrect DLL", which was actually factually incorrect and lead to answers that were valid, but did not solve my problem.

Even if a Visual Studio project has a reference to a local and/or modified copy of a assembly that is in the GAC, it will be used during the compilation, but at runtime, the CLR will always load the assembly from the GAC, even if it is sitting right there in the same directory as your application.
So the solution does not involve figuring out a clever way to pack or deploy the modified assembly, but figuring out a way of making the CLR actually load it if it's there.
Two possible solutions:
1) Use a role startup task and an installation project to deploy the modified version of the assembly in the production server's GAC.
2) Remove the signature of the assembly and make sure all references are made to this version without the signature. Beware other assemblies that may be referencing the original signed version and will try to load it from the GAC.
For more details and links see How to prevent a .NET application to use an assembly from the GAC?

ClickOnce installing old assemblies from cache

I'm using ClickOnce for installing my application written in C#. Everything worked fine till the last update after which start of my application ends with an error saying:
Could not load file or assembly MyAssembly... HRESULT: 0x80131040.
After some research I've found that there is an old version of MyAssembly located in my application's ClickOnce cache folder (C:\Documents and Settings..\Apps\2.0...). However there is an actual version in the deployment package.
I've also found this old version of MyAssembly in a standalone directory in the ClickOnce cache named after this assembly (plus some characters added).
It seems to me that for some reason ClickOnce used this old version of MyAssembly from the cache instead of the new version from the deployment package.
Uninstall/install of my application won't help.
How is this possible?

I have had the same behaviour. It mentioned the problem in another question. Since then, it has happened several times for us with different applications. One strange thing is that it behaves differently on different computers. So one computer could have been updated with the new assembly while another got the old one copied.
.NET ClickOnce deployment and wrong assemblies called after updated version
This appears to be a bug in .NET framework 3.5 SP1.
See Microsoft KB 971052.

Make sure this old assembly is loaded. You can use DllProfiler for that.