I attempt to open and build a WPF solution in Visual Studio 2022. However, I get this build error:
Could not resolve this reference. Could not locate the assembly "Microsoft.Expression.Drawing". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
A similar issue has been posted before regarding Microsoft.Expression.Interactions here. However, how can I resolve the issue for Microsoft.Expression.Drawing? I've installed the Microsoft.Xaml.Behaviors.Wpf NuGet package.
The new Microsoft.Xaml.Behaviors.Wpf NuGet package replaces the System.Windows.Interactivity types that were shipped as part of Blend. It does not provide Microsoft.Expression.Drawing types.
The expression blend assemblies are deprecated and not shipped anymore. The Blend for Visual Studio SDK for .NET could be installed until Visual Studio 2017 and found here:
C:\Program Files (x86)\Microsoft SDKs\Expression\Blend\.NETFramework\v4.0\Libraries
C:\Program Files (x86)\Microsoft SDKs\Expression\Blend\.NETFramework\v4.5\Libraries
You could download Visual Studio 2017 (Community is sufficient) and install it from there.
The original Blend SDK was still provided by Microsoft for download as standalone about a year or two ago, but now all the links are dead. Fortunately, there is a snapshot on Wayback Machine where you can reach the original download.
Other than that there are only unofficial sources like these NuGet packages:
Expression.Blend.Sdk.WPF
Microsoft.SDK.Expression.Blend
If you can, please stick to the original SDK, since unofficial packages may contain any code, including malware. They might impose a security risk or contain assemblies not allowed for redistribution.
Related
Is Roslyn the default compiler in Visual Studio 2017?
I found this article
which tells that Roslyn is not the default compiler and you should install Nuget packages to enable Roslyn.
Nuget packages:
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers
But I also saw an answer on stackoverflow that says, Roslyn is the default compiler starting from VS 2015.
And when i am install that nuget packages, it's creating a new folder in /bin
with name 'roslyn'
Yes, Roslyn is the default compiler in Visual Studio.
In the article you link, it only says you need to install it separately if you are trying to use it without Visual Studio:
To date, Roslyn has remained a part of Visual Studio 2015 and is installed together with it. Roslyn is a part of Visual Studio 2017 as well. It has been released in March 2017.
However, Roslyn is not included in the .NET Framework. Even in the .NET Framework 4.6 version, the traditional csc.exe and vbc.exe compilers are included. This is done for it to be compatible with previous .NET Framework versions.
To install Roslyn compilers without installing Visual Studio, you need to download and install Microsoft Build Tools. Roslyn can also be downloaded from Github, then you can compile and get binary files csc.exe and vbc.exe, which can be accessed from the command line.
You would typically only need those NuGet packages if you were building an application or service for compiling code (or similar), which is what that article is about. That is, when your application is actually using Roslyn at runtime to process code, rather than itself being built with Roslyn.
I've been trying to use ZipDiff to compare two zip files. I installed ZipDiff through the NuGet Package Manager in Visual Studio which installed the necessary dependencies such "SharpZipLib" as well.
During the installation it was stated that the version of SharpZipLib has to be higher than or similar to 0.86 in order to use the latest version of ZipDiff. It was also mentioned that the SharpZipLib version which got downloaded was higher than 0.86. But when I tried to build the solution I get the following error.
Build error
Then when I checked the properties of the reference that was added, the version was "0.85..".
Properties Window
Then I reinstalled them and did it through the "Package Manager Console" but I got the same result.
Can someone tell me why this happens?
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.
I created a WPF project in VS 2013. After upgrading to VS 2015, this error showed in the designer on types derived from the Blend SDK:
the type from assembly is built with an older version of blend sdk and
is not supported in a windows presentation foundation 4 project
Run Command Prompt as Administrator
Change Directory to Blend SDK: cd C:\Program Files (x86)\Microsoft SDKs\Expression\Blend\.NETFramework\v4.5\Libraries\
Register DLL: gacutil -i System.Windows.Interactivity.dll
Restart Visual Studio
Reference: https://connect.microsoft.com/VisualStudio/feedback/details/755407/xaml-designer-will-not-display-when-using-blend-sdk-behaviors
You can resolve this issue by manually changing the version numbers in .sln and .csproj files.
In .csproj and .csproj.user
change ToolsVersion to your current Visual Studio version. VS 2013 is version 12, VS 2015 is version 14.
In .sln change VisualStudioVersion to the current version, you can find it in the About window.
Also change Microsoft Visual Studio Solution File, Format Version to your current version (eg 14.00, 12.00)
Note: This only works for built-in assemblies. If external dependencies (like Prism) cause this error, you'd have to recompile them using the new Blend SDK. You could also try to update the dependency, maybe the newest version is already compiled using the latest Blend SDK.
None of the other answers here worked for me. What finally solved it was deleting the .NET v4.0 version of the file in the SDK folder:
C:\Program Files (x86)\Microsoft SDKs\Expression\Blend\.NETFramework\v4.0\Libraries\
I am referencing the v4.5 file via NuGet, but it seems that the designer was finding the file in the above folder. The v4.0 file was not registered in the GAC.
The popular answer is valid, but since things are always changing in the developer world, I thought I would note that there's a (IMO) better solution now.
In December 2018, Microsoft released an official, open source, supported NuGet package for XAML behaviors for WPF. (There's a separate one for UWP.) It's very easy to migrate to this package. You need to uninstall your current NuGet package, remove a couple of references, install this package, and change a using statement (or FQN).
https://www.nuget.org/packages/Microsoft.Xaml.Behaviors.Wpf/
https://devblogs.microsoft.com/dotnet/open-sourcing-xaml-behaviors-for-wpf/
I read about it in this SO answer, so credit goes to that OP:
How to add System.Windows.Interactivity to project?
Was having a similar problem using Visual Studio 2017 but none of the answers above fully resolved it for me. Found a Microsoft developer community page that had a workaround that did the trick. Comment by Bran Hagger recommended deleting the .vs folder from the solution's directory. This additional step cleared out the cache and caused Visual Studio to rebuild it.
Just the Microsoft Visual Studio Solution File, Format Version change to 14.00 worked for me.
This also could be that you are mixing different versions of System.Windows.Interactivity.dll, especially if you are getting the SDK from nuget where several different packages provide it, e.g.:
https://www.nuget.org/packages/Expression.Blend.Sdk/
https://www.nuget.org/packages/System.Windows.Interactivity.WPF/
In this case, you'll have to synchronize these libraries among projects.
Deleting the .vs file in the solution folder solved the issue. The issue happened for me after I updated My Visual Studio 2017 and Opened the project that was built before with an older version of Visual studio 2017.
When I include JetBrains-ReSharper my project using NuGet Package Manager, and then I try to rebuild the project, it shows an error.
Error 14 The type 'System.Threading.LazyInitializer' exists in both 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\mscorlib.dll' and 'Project\packages\JetBrains.ReSharper.SDK.8.2.1158\bin\System.Threading.dll' Project\Filters\InitializeSimpleMembershipAttribute.cs
Can anybody can help me to solve the problem ?
Sadly, because ReSharper is a .net 3.5 application, and due to the way the SDK is set up, it includes references to the .net 3.5 compatible System.Threading.Tasks.dll back port Microsoft initially released with RX. The unfortunate part is that this file is referenced even if your plugin is a .net 4 project, and so you get conflicts with the real System.Threading.Tasks.
You can change your project to be .net 3.5, but then (again, due to the way the SDK is set up) you'll get other warnings about .net 4 assemblies that are referenced, but shouldn't be. Essentially, you just have to ignore those warnings. We're working on fixing all of this for 9.0.
However, as #derigel mentions in the comments - adding the ReSharper SDK to an MVC project is a little weird, and frankly, won't work. The ReSharper SDK is for building ReSharper plugin extensions. If you want to install ReSharper, download it from here: http://www.jetbrains.com/resharper/download/