I have two projects under the same solution that both rely on `System.Net.Http' as a dependency. The strange thing is that both projects use different physical dll files, which is causing a runtime MissingMethodException error when trying to run unit tests.
library project uses:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll
test project uses:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
Why are there two instances of the assembly and how can I force VS to use a specific instance? The csproj files do not specify a specific file path:
<Reference Include="System.Net.Http" />
The only thing I can think of is I used the built in "Create Unit Tests" option when right-clicking the method in the library project. I'm guessing this loads a default set of references which does not match when you create a new project.
Related
I'm on V16.4.1 and the project is targeting .NET Framework 4.7.1
I have a solution with multiple projects which all run fine except one which gives the above error. I searched the project and can't find any using references to it and just in case, I added the dll to my references. I searched the entire solution in case I was referencing it through another project but there is no reference to it anywhere
I tried deleting bin & obj folders. Cleaned and rebuilt the project but I get the same error every time.
Edit: The project can build, this only happens when I try to debug it
bin\roslyn\csc.exe is throwing the exception
Could not load file or assembly 'System.Collections.Immutable,
Version=1.2.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
I use
Visual Studio Professional 2019 ver 16.7.6 / Preview: 16.8.0 Preview 4
and I found the same problem with many 'old' project using .net framework when I compile them from scratch (i.e. deleting bin/obj directories).
The compiler does not recognize that the runtime needs this package, and the solution is to copy in the bin directory the requested version (1.2.3.0 in this case) of DLL System.Collections.Immutable.dll
You can download it adding this line to packages.config file:
<package id="System.Collections.Immutable" version="1.2.3.0" targetFramework="net471" />
but still need to manually copy the .dll in bin directory.
Or add the package with Nuget.
Stefano's answer worked for me
this file is a dependency from my firebase dll, tough i didn't need to modify packages.config because the file exists in my bin folder
I just included System.Collections.Immutable.dll file in in VS project
then changed in file properties > advanced > copy output > copy always
thanks!
I have a .net core library project and another Asp.net core project referencing this library project.
The library project references an assembly that has x64 and x86 versions and I want to reference the version according to the PlatformTarget property value.
I've seen this question and already used their solution except that I'm using PlatformTarget instead of creating a custom property, here is project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<Configurations>Debug;Release</Configurations>
<Platforms>AnyCPU</Platforms>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<Reference Include="STPadLibNet, Version=8.4.3.0, Culture=neutral, PublicKeyToken=a0c5b3c72d40bbc6">
<HintPath>$(PlatformTarget)\STPadLibNet.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
The assembly I'm trying to reference is called STPadLibNet, 64bit version is located in x64 folder in Project directory and 32bit version is located in x86 folder.
For some reason dotnet build always resolves to x64 folder even if the platform is set to x86 resulting in BadImageFormatException at application startup.
I've read about assembly probing and I now understand that when assembly resolver finds the assembly under Project directory or its subdirectories it ignores the HintPath, I tried using different file name for dll like STPadLibNetx64.dll for the 64-bit version and STPadLibNetx86.dll for the 32-bit version and reference the correct version like this:
<HintPath>STPadLibNet$(PlatformTarget).dll</HintPath>
For some reason the dll file is copied to my library project output directory but it's not copied to the asp.net core project output directory resulting in Assembly not found exception at startup, Also Rider(the IDE I use) shows that the assembly is not resolved by MSBuild.
So how to tell dotnet build to use HintPath ? or how to reference the correct version of the assembly according to PlatformTarget?
Notes:
I'm using .Net core 3.1 and my IDE is Rider 2019.3, OS Is windows 10 x64 1909 and Programming language is C# 8.
the assembly I'm referencing is a hardware SDK which I can't change for obvious reasons
I don't want to create two projects and I prefer not to create some dummy project.
In The End, I moved x86 and x64 folders containing STPadLibNet.dll outside the Project Directory to the Solution Directory, this way HintPath is respected again.
I just recently delved into Roslyn compiler stuff and I'm wondering about some possibilities. I'm trying to build Roslyn compiler from Roslyn repository using features/tuples branch and replace the needed DLLs in VS15Preview\MSBuild\15.0\Bin folder. But when I replace DLLs and build console app project I receive the following error message
Severity Code Description Project File Line Suppression State
Error The specified task executable "csc.exe" could not be run. Could not load file or assembly 'Microsoft.CodeAnalysis.CSharp, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Files which I try to replace: Microsoft.CodeAnalysis.dll, Microsoft.CodeAnalysis.Csharp.dll and csc.exe.
Is it possible to build your custom Roslyn compiler for C# and replace it within VS15 Preview?
One way of going about it is to set the CscToolPath msbuild variable to your new roslyn build's bin directory.
I find the msbuild commandline (e.g. Start > Developer Command Prompt) the most convenient for this. You can just cd into any solution directory on run:
msbuild /p:CscToolPath=<PathToYourRoslynBinDir>`
You can also do it inside a .csproj if you do it more often:
<PropertyGroup>
<CscToolPath>C:\your\roslyn\bin</CscToolPath>
</PropertyGroup>
Obviously, this only affects the build, not Visual Studio or it's intellisense. To hook that up, you need to follow the Trying Your Changes in Visual Studio guide in the Roslyn repo. You have to build one of the VSIX projects in the Roslyn solution. Running one of those projects launches an experimental instance of Visual Studio where you can play around with your changes.
M0sa's answer might work, however, that will only give you MSBuild enabled builds. If you also want to test it in VS, then you can follow Roslyn's own documentation. That page tell you how to replace the "intellisense" in Visual Studio (the VisualStudioSetup bullet), and the Ctrl-Shift-B "Build Solution" to actually run your solution (the CompilerExtension).
If you just want to try out your build of Roslyn, you can do that by opening Roslyn.sln in VS15 and then running the Roslyn project (with or without debugging). It will start a new instance of VS15, which uses your build of Roslyn.
I am getting this exception in the main Project PrismDashboard:
Source\PrismDashboard\bin\Debug\PrismDashboard.vshost.exe
System.Windows.Markup.XamlParseException occurred
HResult=-2146233087
Message=Could not load file or assembly 'Microsoft.Expression.Interactions, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
This is the project with Bootrstrapper and Shell. It is happening because Shell is using ModuleA from another Project:
Source\Modules\ModuleA
That requires refrence to Microsoft.Expression.Interactions and I can see that this DLL exists in:
Source\Modules\ModuleA\bin\Debug
I'm not getting compile error, and I'm getting runtime error.
ModuleA View will be injected into Shell Region, and this View requires Microsoft.Expression.Interactions which is referenced in ModuleA project but not in the main Project with Bootstrapper and Shell.
I don't want to add reference to DLL's required by other projects in my main project.
Have tried to set Embaded Interop Types on reference in ModulaA but getting error:
Error 1 Cannot embed interop types from assembly 'c:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.0\Libraries\Microsoft.Expression.Interactions.dll' because it is missing either the 'ImportedFromTypeLibAttribute' attribute or the 'PrimaryInteropAssemblyAttribute' attribute c:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.0\Libraries\Microsoft.Expression.Interactions.dll ModuleA
Error 2 Cannot embed interop types from assembly 'c:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.0\Libraries\Microsoft.Expression.Interactions.dll' because it is missing the 'GuidAttribute' attribute c:\Program Files (x86)\Microsoft SDKs\Expression\Blend.NETFramework\v4.0\Libraries\Microsoft.Expression.Interactions.dll ModuleA
The main application needs to be able to find Microsoft.Expression.Interactions in order to load module A, no way around it. Also keep in mind when you distribite your application the same rule applies.
If you really don't want to reference that assembly in your shell project (which btw is actually the easiest way since it will copy it to the main application's output dir so you're settled) the only other option is copying it there manually. Could be done using a post-build event, but by doing that you're also tieing both projects together since they need to know about each other's output directory. Another way is making all projects put their output in the same directory. I'v been using that for some pretty large scale applications and it works nicely. Also distributing the application is then just a matter of copying that entire directory.
For last couple hours i have been trying to generate a Unit Test for a Silverlight application.
A number of posts refer to a "Silverlight Unit Test Project" which is part of the Silverlight Toolkit. But I downloaded the toolkit and still do not have the Test Project, it seems to be only available in VS 2010?
I have added a "Silverlight Class Library" project and added references to:
Microsoft.Silverlight.Testing
Microsoft.VisualStudio.QualityTools.UnitTesting.Silverlight
and the following TestClass:
using Microsoft.Silverlight.Testing;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace UnitTesting
{
[TestClass]
public class Class
{
[TestMethod]
public void TestMethod()
{
.....
}
}
}
But there are no tests being discovered by Visual Studio 2012 Test Explorer. Even after re-build of solution and restart of application.
Anyone have any ideas? Is this even possible?
This link has the answer that worked for me:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/5e991b0d-8061-4c4e-a17d-82b4abd58d6c/vs-2012-silverlight-unittest
I recommend starting a new Silverlight project and installing the
SilverlightToolkit-Testing NuGet package. In your test files, put in
usings for Microsoft.Silverlight.Testing and
Microsoft.VisualStudio.TestTools.UnitTesting and use regular
[TestClass] and [TestMethod] attributes. To run them, you can use the
Toolkit test runner by putting RootVisual =
UnitTestSystem.CreateTestPage(); in your App.Application_Startup(),
use Silverlight Unit Test Adapter (which currently is at v0.0.1 and
doesn't really work), or (the best approach by far) install ReSharper
and the AgUnit plugin.
To complete this thread,
The Silverlight DLLS are located in C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\Toolkit\dec11\Testing
I could not get Resharper 7.1 to run the tests but this library helped. You will need to extract using 7-zip so that the DLLS are not blocked. Then restart Visual Studio 2012 and Resharper will run your unit tests.
I believe that you need to install the Silverlight Unit Test Adapter to get the tests to show up in Test Explorer
http://visualstudiogallery.msdn.microsoft.com/caca1e81-becb-41e4-9110-bc247f3f400b?SRC=VSIDE
I was able to run some tests:
Given Visual Studio 2012 Professional(with test runner).
Create class library targeting .NET 4.5 with name like MyProject.Tests.
Reference C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll or from your location.
Add test as usual test for .NET 4.5.
Add project reference to MyProject - project targeting Silverlight 5.
Add some tests. Build. May get error of missing reference:
Error 12 The type 'System.Xml.Serialization.IXmlSerializable' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'
Reference C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Xml.dll
Build and get same error. Open *.csproj and ensure hint path:
xml
<Reference Include="System.Xml">
<HintPath>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Xml.dll</HintPath>
</Reference>
Run test, e.g. via right click on TestMethod -> Run Tests. May get error:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified.WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Fix is:
<Reference Include="System.Windows">
<HintPath>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll</HintPath>
</Reference>
Notes:
Recall that Silverlight 5 assemblies are in the same format as .NET 4.5.
Test fail because .NET 4.5 assemblies are default for project, we need to override via HintPath. I think there may be other way via MSBuild scripts modification and/or assembly binding redirection.
.NET core assemblies are loaded from 4.5, if these differ from Silverlight things may fail. I hope not.
Features depending on Silverlight hosting runtime may fail. Like showing Silverlight window or access HTML DOM. Which is good indicators to refactor code to be Silverlight agnostic. Possible error:
Test Outcome: Failed
Result Message:
System.DllNotFoundException: Unable to load DLL 'agcore': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Result StackTrace:
at MS.Internal.XcpImports.Application_GetCurrentNative(IntPtr context, IntPtr& obj)
at MS.Internal.XcpImports.Application_GetCurrent(IntPtr& pApp)
at System.Windows.Application.get_Current()
indicates need to load ActiveX runtime for SL into process.
Referencing Silverlight Toolkit versions of testing assemblies(with [TestMethod] attribute inside) instead of .NET one leads to issue that tests are visible, but not run.