We Keep Coding

GENERATEFAKES of MS Fakes fails with CS1705 sporadically

On my machine the unit test project build fails since a few days but not every time. On the machine of my colleague it fails also sometimes but most of the time he just needs to rebuild and build succeeds.
Assembly 'xx' with identity '...' uses 'System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' which has a higher version than referenced assembly 'System.ValueTuple' with identity 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' [PathToTestDir\obj\Debug\Fakes\xx\f.csproj]
3> GENERATEFAKES : error : project compilation failed with exit code 1
I have checked all nuget references in our solution of all projects (also in project.assests.json and packages.lock.json) and all of them are referencing System.ValueTuple package Version 4.5.0 (assembly version 4.0.3.0).
In packages.lock.json I see the following dependency at this json path:
dependencies[".NETFramework,Version=v4.6.2"]["Microsoft.CodeAnalysis.Common"]
which is this one:
"Microsoft.CodeAnalysis.Common": {
"type": "Transitive",
"resolved": "2.8.0",...
and this contains a dependency to:
"System.ValueTuple": "4.3.0"
which has assembly version 4.0.2.0.
What I also see in the generated f.csproj file is this hintpath:
<Reference Include="System.ValueTuple">
<HintPath>[PathToXX]\bin\Debug\System.ValueTuple.dll</HintPath>
<Aliases>svt</Aliases>
<EmbedInteropTypes>False</EmbedInteropTypes>
</Reference>
But at this path the correct version 4.0.3.0 is located. The whole
source and all bin output folders do not contain a version 4.0.2.0,
except in the obj folder for those fakes generated assemblies.
For all other projects that we reference as fakes the MS Fakes tool is generating this hint path:
<Reference Include="System.ValueTuple">
<HintPath>C:\Users\myuser\.nuget\packages\system.valuetuple\4.5.0\ref\net461\System.ValueTuple.dll</HintPath>
<EmbedInteropTypes>False</EmbedInteropTypes>
</Reference>
Our solution contains several net462 classic projects (Package Reference Style) and also some sdk style projects, some of our project do also reference Asp.net core 2.1. Our unit test project is using Microsoft Fakes and MS-Test since years. We are using VS 2022 (17.1.6).
What I have tried so far:
Closing VS, deleting all bin and obj folders, deleting nuget cache, restarting VS, rebuilding (it worked one time for me so far, but now I am stuck again for days now)
Setting AutoGenerateBindingRedirects and GenerateBindingRedirectsOutputTypeto in the unit test project to True
Also in the .fakes file I tried to set these two properties (even when GenerateBindingRedirectsOutputType makes not much sense for fakes assembly).
Tried out this SO answer
so my fakes file looks like this after these unsuccessful attempts:
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/" Diagnostic="true">
<Assembly Name="xx"/>
<StubGeneration>
<Clear/>
<Add Interfaces="true"/>
<Remove TypeName="xyz"/>
</StubGeneration>
<!--Shim do not make sense for interfaces-->
<ShimGeneration>
<Clear/>
</ShimGeneration>
<Compilation>
<Property Name="PlatformTarget">x64</Property>
<Property Name="AutoGenerateBindingRedirects">True</Property>
<Property Name="GenerateBindingRedirectsOutputType">True</Property>
</Compilation>
</Fakes>
I would appreciate any help or hint so much, thanks!
EDIT:
I also see these warnings in the output window:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2301,5): warning MSB3277: Found conflicts between different versions of "System.ValueTuple" that could not be resolved. [[PathToMyTestProjectFolder]\obj\Debug\Fakes\xx\f.csproj]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2301,5): warning MSB3277: There was a conflict between "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". [[PathToMyTestProjectFolder]\obj\Debug\Fakes\xx\f.csproj]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2301,5): warning MSB3277: "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not. [[PathToMyTestProjectFolder]\obj\Debug\Fakes\xx\f.csproj]

As stated in my comment above, I have found a workround for our situation:
Within the project that should be faked we have introduced last week a c# tuple in an interface method signature. I have changed the tuple to a class so now the interface does not need the c# tuple anymore. The build succeeds but the three warnings I mentioned in the OP at the end of the post are still there.

The type 'HttpResponseMessage' is defined in an assembly that is not referenced

I am just trying to build my application without visual studio by using MSBuild.
Using
Visual Studio Build Tools 2017.
Dot Net framework 4.6.1 SDK
MSBuild auto-detection: using msbuild version '15.9.21.664'
Full Error Message :
error CS0012: The type 'HttpResponseMessage' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Any idea why? Thanks...
Update
This is the dll path with visual studio
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
This is without visual studio, only with MSBuild
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet\Plugins\CredentialProvider.Microsoft
File path is different. How can I fix this?

It seems that your project has used a newer version dll about System.Net.Http and if some dependencies use the old version 4.0.0.0 System.Net.Http.dll, it will miss the old one.
Besides, please the following steps:
1) make sure that your xxx.csproj file has this node, if not, you should modify like this:
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
Also, try to set Copy Local of System.Net.Http.dll to true.
Modify such node like this in xxx.csproj file:
<Reference Include="System.Net.Http">
<Private>True</Private>
</Reference>
2) open CMD as Administrator and then type:
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools
gacutil /i xxxxx\System.Net.Http.dll(path where the System.Net.Http.dll exists)
// like the path C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
3) Maybe you could try this in app.config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Net.Http"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0"
newVersion="4.2.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
There is a similar issue about it.
4) then delete bin and obj folder and then use Build Tool for VS2017 to build the project again.
=====================================================
Update 1
Thanks for sharing your solution. Actually, Not sure that whether system cannot find the System.Net.Http when you move your project into Build agent.
Actually, you can use hintpath to force the path to reference System.Net.Http in your project and make sure that they are the same. Also, this solution will make sure the dll will copied into output folder. And it will make VS or msbuild find and identify the DLL.
And you have changed the location of the DLLL to the same so that the issue is fixed.
You can try to use this in your xxx.csproj file:
It will also copy such dll into output folder.
<Reference Include="System.Net.Http">
<HintPath>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll</HintPath>
</Reference>
or
<Reference Include="System.Net.Http">
<HintPath>C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll</HintPath>
</Reference>

In your web.config or App.config add:
<compilation debug="true" targetFramework="4.6.1" />
<assemblies>
<add assembly="System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</assemblies>
</compilation>

Azure Devops build not restoring automapper nuget

I am trying to build a .Net project but it doesn't find Automapper v3.3.1.
I have the following build steps:
Use NuGet 4.3.0
NuGet restore
Build solution ...
When running step 3 it gives the error:
Error CS0246: The type or namespace name 'AutoMapper' could not be
found (are you missing a using directive or an assembly reference?)
In the Nuget Restore step I have the
Path to solution, packages.config, or project.json set to the .sln file.
Under Feeds and authentication I checked the option Feeds and in my NuGet.config I left path to NuGet.config empty since I have a global Nuget.config file on the build server under:
C:\Users\user\AppData\Roaming\NuGet\NuGet.config
In this file I have the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
<AzureDevOpsFeed>
<add key="Username" value="MyUsername" />
<add key="PAT" value="MyPatKey" />
</AzureDevOpsFeed>
</configuration>
I would assume the build would use the package source https://api.nuget.org/v3/index.json to restore Automapper.
Any idea why this is not working?

The solution quoated from
NuGet not restoring packages on build
I had to go into Source Control and delete all of the files in the
packages folder (except repositories.config) before NuGet would
restore the missing packages. The idea is that you are using package
restore rather than checking your packages in to source control. If it
sees the packages in source control, it won't download them.

I had same problem. Try to delete nuget packages folder and rebuild the solution.

how to set relative path in nuget.config?

I currently have the following nuget.config file. With automatic package restore it will create a package folder that is one level up from my solution folder. For example if my solution folder is on my desktop, the package folder will be generated within a /lib folder on my desktop. I would like for it to generate the /lib folder within my solution folder. How do I change the relative path to accomplish this?
<configuration>
<solution>
<add key="disableSourceControlIntegration"
value="true" />
</solution>
<config>
<add key="repositoryPath"
value="../lib" />
</config>
</configuration>
For example,
Bad: \desktop\lib\
Good: \desktop\mysolution\lib\
I tried this:
<config>
<add key="repositoryPath"
value="/lib" />
</config>
..and the package restore directory becomes c:\lib which is unexpected behavior.

In addition, please make sure your NuGet.Config file is added under your solution directory after you use "lib" path in that path.

I discovered that if I remove
<config>
<add key="repositoryPath"
value="../lib" />
</config>
...from nuget.config
Or
if I complete delete nuget.config (and use all defaults)
That the default behavior will be to create and add packages to this folder:
\desktop\mysolution\packages\
and while that is not named 'lib' it hardly matters - my key issue was to get the packages in to the solution folder.

Change Build Output Directory of WebApi Application

I am part of a team working on a large application. I am a new addition to this team and am building a new piece of the app. As part of this process, I've created a WebApi application that will expose some HTTP endpoints through which I will retrieve information about the app.
Due to conditions it would take far too long to explain, I'd like to get the WebApi project to build in another directory, specifically ..\bin\Server\Debug\ as this is where most of the other portions of the app build to. I would not bother except that the app tried to use files that are found based on the working directory which is currently wrong for my WebApi app.
I tried changing it in the project settings and now I get this error:
My Googling has turned up little help thus far. Anyone know how to resolve this?

Try adding a runtime probing path in the configuration:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin\server\Debug;"/>
</assemblyBinding>
</runtime>
</configuration>
In addition to above step and to get rid of globa.asax error. Open the mark up of Global.asax file and Add follow line on the top.
<%# Assembly Name="<you_web_app_assembly_name_here>" %>
Now you'll start getting the error of System.web or BindingProvider not found etc. There's weird fix for it start adding assemblies to assembly tag under compilation.
<compilation debug="true" targetFramework="4.5" optimizeCompilations="false">
<assemblies>
<add assembly="Microsoft.AspNet.Identity.Core, Version=2.2.1, PublicKeyToken=31bf3856ad364e35" />
<add assembly="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Optimization, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</assemblies>
</compilation>
You'll get few more errors like this but this will get you going.
Reason: The problem I see is that there's an option to change the output path but Asp.net does on the fly compilation. Which why the error are compilation related when you try to run the website. Somewhere the run time compilation only look in \bin folder and which is why we have to specify every assembly that the project is referencing to.
Update -
Unfortunately you can not change the bin directory. After looking at all options and digging found that bin folder of Asp.net web project is not ordinary binary output folder. It's a share code folder from where the binaries are referenced directly in the project.
The binaries are compiled when a first request is received by webserver for Asp.net application. And bin folder is only use as shared binary references folder and not the actual output folder/directory.
The actual output folder of On-the-fly compilation in Asp.net is default set to %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\Temporary ASP.NET Files that you can change ofcourse from compilation tag attribute [tempDirectory][3] in your web.config.
After all these research I came to this conclusion that the option for changing the directory from project -> properties -> Build -> Bin is appearing because of Asp.net website project template. This gives the user same look'n feel as any other project. But the functionality of asp.net website remains the same. The Bin folder still works as it used to work in old website template of Asp.net.

You cannot change the output directory of an asp.net application due to IIS security restrictions, this is why it is not working.
If you are trying to manage dlls due to DI, copy all other satellite dlls into bin folder of your main asp.net app

You can try copying the dll with the after build target. First change the output path back to what it was if you changed it before. Then add some code like this in your project file.
<target name="AfterBuild">
<copy destinationfolder="..\bin\Server\Debug\" overwritereadonlyfiles="true" sourcefiles="$(OutputPath)\$(AssemblyName).dll" />
<copy destinationfolder="..\bin\Server\Debug\" overwritereadonlyfiles="true" sourcefiles="$(OutputPath)\$(AssemblyName).pdb" />
<copy destinationfolder="..\bin\Server\Debug\" overwritereadonlyfiles="true" sourcefiles="$(OutputPath)\$(AssemblyName).xml" />
</target>
This will put the built dll in to the folder specified in destinationfolder. I usually use this for class libraries but i don't see why it would not work for a web api project
You can check out my blog post on this if you like.
http://torontoprogrammers.blogspot.com/2014/11/msbuild-targets-and-tasks.html