Develop Reference

msbuild copies nuget package lib from different location then packages\*package_name*?

I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(

So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.

ClickOnce Publish does not publish updated NuGet package

When I publish my application (using Visual Studio), I always end up with the same (old) NuGet package version of a library, i.e. the updated package does not get published, therefore will not be installed and therefore the application crashes on startup (after being updated) as the required dependency was not found.
That's how my solutions looks like:
Solution\
LibraryProject (with NLog (5.0.0-preview.1) added/updated via NuGet)
MainAppProject (gets published)
Before updating the NLog library, it was at version 4.7.10. That's the version the first published version of the App was shipped and installed with.
Now after I updated the NuGet package, the publish process still ships the old 4.7 version (looking at the dll file properties in the publish folder). Yet in all bin\ and obj\ folders I see the new dll.
Also, in the output of the publish build, I see the new version used:
2>-r:"C:\Users\dev\.nuget\packages\nlog\5.0.0-preview.1\lib\netstandard2.0\NLog.dll"
I also switched to "Produce single file", which deletes the .dll files in the publish folder, also without any success. Switching back to non-single file also results in the old version published again.
Any ideas what I'm missing or where the old file version comes from? How can I further debug this issue (can I build with more verbose logging, if so, how?)
(I've also tried the obvious things: cleaning the solution and restarting Visual Studio)

Found it!
Cleaning the solution did not clean the obj\Release\...\R2R (ready to run) folder. That's where the old dll version was. Manually deleting this folder fixed the problem for me.

Visual studio won't read .pdb from my nupkg

I have generated some nuget packages containing .pdbs with the following:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
I have verified the .pdbs are within the .nupkg generated in the lib/*/ folder next to the dll's.
However, when I consume these nuget packages in Visual Studio 2017, it only extracts the .dll's and not the .pdb's. Leaving me unable to debug into the package.
What am I doing incorrectly?

Since you can make sure the .nupkg contains the .pdb file. please make sure both the projects are in debug mode.
Consuming a nuget package locally sometimes has some difference from installing it from nuget.org. The .pdb source won't be found in solution. By default, the .pdb will locate under path like :C:\Users\xxx\.nuget\packages\PackageName\xxx.
Update:
If the nuget package project and the project which consumes it is on the same machine. The AllowedOutputExtensionsInPackageBuildOutputFolder property is enough. Since you have source files on same machine, and the debug engine can easily find it so that you can step into it.
But if for a scenario like this: You developed the nuget package. And share it to other team members. To make them can Step into you should embed the xx.cs files into the .nupkg.
Under this circumstances, the AllowedOutputExtensionsInPackageBuildOutputFolder may not work. I can't find a way to embed source files using it. You may need to use a nuget pack command like this issue. Actually, the way Stephan packed the project is correct. I've checked it work and will embed the source files and .dll and .pdb into the .nupkg. Of course, in this way you need to add the path to source files repo by Solution=>Properties=>Debug Source files:
In addition: You can add the nuget pack command in a post-build event, so that every time you build a project successfully, it will package for you.
Also, you can consider source links as source control so that you won't configure the source path by Solution=>properties.

Failed to run reference rewriter with command error with unity error when adding a DLL to the assets folder

I have encountered this error when I am adding the DAI.dll to the assets folder.
this error happens when I try to build.
UnityException: Failed to run reference rewriter with command --target="Temp\StagingArea\DAI.dll" --additionalreferences="Temp\StagingArea","C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0\Facade","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.AI.MachineLearning.Preview.MachineLearningPreviewContract\1.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.Calls.CallsVoipContract\3.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.SocialInfo.SocialInfoContract\2.0.0.0","C:\Program Files (x86)\Windows Kits\10\References.....(followed by alot more of this)....
I am using visual Studio 2017 version 15.7.3 and Unity version 2017.2.0b7
I have added the DLL to the assets folder in unity.
These are my player and build settings.

You need to change the settings in unity (Settings example in the photo below):
Find your dll file in your project inside Unity.
Click on it once to highlight it.
You will see the dll options in the Isnpector
Usually for HoloLens, you only select "WSAPlayer"
Click Apply to save settings.
Rebuild
Warnings
Sometime the dll that you trying to include is referencing something else is not included and that's why it will not work, but the error will be different than what you got.
Sometimes you may need to import an older version of the DLL. For example, I tried to import Newtonsoft.Json 11.0.2, but 11.0.2 was referencing a newer core framework than the solution that unity generate. There is a way to update it, but I didn't want to deal with it every time, so I found out that the highest version that I can use is 9.0.1 (I had to skip 11.0.2, 11.0.1, 10.0.3, 10.0.2, 10.0.1).
Also, keep in mind that you should include netstandard dll.
I usually have UWP test project in hand to try to test my dll with it. If it works there, then it is a good first step that it may work after importing it to Unity assuming it does not have dependencies.
Last result workaround
You can comment the code that references your dll
build the project from unity without the dll
in the generated UWP solution, you can add dll normally and even use nuget to install your desired dll
Uucomment your code.
Build your solution then deploy to your device or create a package to deploy it to device or store.
This works nicely as a work around.
One issue with this is that you will need to import dll or install nuget every time solution generated if it was deleted. It gets annoying and if you are working with a team, it can get confusing when they get the project and think that it does not work. Meaning you need to do more work to communicate and deploy.
Second issue, Unity is moving away from .NET backend to IL2CPP (I don't think you can do this in the CPP generated project). Meaning this is a short term workaround.
Consider upgrading to Unity 2018.2
Using .NET 4.X instead of .NET 3.4 Equivalent made my life easier with references and issues related to references and using more modern C# code.
You can install it and still keep the 2017 version if you install Unity Hub. This will minimize the risk of considering the update.

How to see source code from github in Visual Studio IDE, but compile with dlls from Nuget?

Nowadays there's a lot of great open source packages and frameworks for all sorts of uses. Let's take for example, ASP.NET Core MVC and Newtonsoft.Json.
Those are shipped in Nuget packages, which are stripped of the source code.
I think many of you can remember a lot of situations in which one would like to see the source code freely available on GitHub (to help debugguing some issue), but was forced to do one of the following:
Be lazy and just forget about it, or continue debugging your issue with a popular library treating it more like a "black box";
Go to the browser, type github.com and search the source code without the mighty advises of the Visual Studio IDE;
Spend 5 minutes, clone the repository to the local drive and look at it with IDE;
Spend even more time while compiling the source code, deinstalling all of the nuget packages of interest from your projects and instead, hooking up directly to all of the freshly compiled assemblies (which are not always one-to-one to Nuget package).
This last option is the most viable, but you're left with a lot of time spent and you can't just push this to your repository or deploy the compiled code anymore. Other developers won't find those relative paths to the dlls and customers may end up with wrong versions of nuget packages baked in the deployment package.
Is there a fifth option which has all the pros of the fourth, but none of the cons? I imagine this being done by an IDE in an isolated fasion, i.e. no modification to my .csproj and package.config files, but the "Go to definition" & "Find all references" features and debugging should work as if I'm hooked up to the real stuff.
Yes, I'm pretty lazy.

Please pack the package as symbols package and then put the PackageName.Symbols.nupkg file with the ProjectName.nupkg file on the same package server after you downloading the package source code. I’m using following steps to debug my NuGet package source code in Visual Studio IDE.
Create my NuGet package project and implement the function that I want. In your situation, you just need to download the package source code from Github.com.
Build the project in your Visual Studio IDE, it will general a dll file and a pdb file in bin\Debug folder.
Download NuGet.exe and run this command to pack the source code project to package:
NuGet Pack MyProject.csproj -Symbols
There will generate two files, one is ProjectName.symbols.nupkg and another is ProjectName.nupkg. Upload these files to your NuGet Server. And you also can put them on your local driver.
Add your NuGet Server into your Visual Studio IDE through Tools -> Options -> Package Manager Console -> Package Source.
Open your project and install the package from the added package source.
Right-click your solution, choose Properties -> Common properties -> Debug Source Files, add the path where the PackageName.Symbols.nupkg file with the ProjectName.nupkg file stored on your local machine.
Now when your start debug your project and press F11 step into one function in your installed package, it will step into then package source code.

as mentioned in one of the comments, there is a VS extension that does this:
Nuget Reference Switcher (select one that matches your VS version to install), for more info, you can read its wiki on github.
here is what I usually do:
git clone the source repository
add the open sourced .sln/.csproj to your own solution:
run nuget reference switcher extension
This is equivalent to your step 4, but a lot less work since the heavy lifting is done by the extension.