Develop Reference

VS2019 RegPkg.exe throws Unhandled Exception

I've just installed Visual Studio 2019 with SDK and when i try to run RegPkg.exe, I see the following error. I don't have any other VS instances installed on the machine but I'm confused why the error is reporting about version 15.0.0.0 (which is VS2017).
Can someone please help me to resolve this error.
Unhandled Exception: System.IO.FileNotFoundException: Could not load
file or assembly 'Microsoft.VisualStudio.Shell.Framework,
Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
at Microsoft.VisualStudio.Tools.RegPkg.Main(String[] arguments)

I just noticed I got the exact same error message, using VS 2017's version. So it has nothing to do with the version you are using. I don't even have 2019 installed.
Microsoft simply broke their SDK, which has apparently been broken for 2 years, and no one noticed. For reference, I'm using VS 2017 15.9.7, also with the VSSDK installed.
I have a NuGet reference to that DLL in a VSIX extension I build, so I had a copy in my .nuget package cache ("%USERPROFILE%.nuget\packages\microsoft.visualstudio.shell.framework\15.9.28307\lib\net45\Microsoft.VisualStudio.Shell.Framework.dll"). I copied that version into the folder where regpkg.exe is located, and resolved the error (%VSSDK150INSTALL%\VisualStudioIntegration\Tools\Bin).
Probably not the best solution, but Microsoft needs to fix their product. I suspect it broke as part of their reorganization for the 2017 product, as they also added all the assemblies that extensions need for dependencies to NuGet. I guess they forgot to keep that assembly in the actual VS install folder.
EDIT: I've been looking into this more, and apparently the file actually exists in the lib sub folder right there with the exe. However none of the versions I've found actually work with CreatePkgDef.exe which was my backup plan, as it now throws this error instead:
CreatePkgDef : error : ArgumentException: No Visual Studio
registration attribute found in this assembly. The assembly should
contain an instance of the attribute
'Microsoft.VisualStudio.Shell.RegistrationAttribute' defined in
assembly 'Microsoft.VisualStudio.Shell.Framework' version '15.0.0.0'
Seems to work with regpkg.exe, though I haven't tried every combination of options.

System references in bamboo

I have installed one nuget package in my project which has dependency on some of the system dlls like system.IO/system.Reflection etc. So when I install that nuget package everything works fine in my local. However, when I push my code to bamboo (build server) I start getting multiple assemblies error:
26-Mar-2019 05:30:23 CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'E:\agt01\ENS-EB577-BEQI\Bin\Packages\System.Xml.ReaderWriter.4.3.0\lib\net46\System.Xml.ReaderWriter.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.Xml.ReaderWriter.dll'. Remove one of the duplicate references. [E:\agt01\ENS-EB577-BEQI\myProject\myProject.csproj]
26-Mar-2019 05:30:23 CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'E:\agt01\ENS-EB577-BEQI\Bin\Packages\System.Runtime.InteropServices.4.3.0\lib\net462\System.Runtime.InteropServices.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.Runtime.InteropServices.dll'. Remove one of the duplicate references. [E:\agt01\ENS-EB577-BEQI\myProject\myProject.csproj]
26-Mar-2019 05:30:23 CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'E:\agt01\ENS-EB577-BEQI\Bin\Packages\System.Reflection.4.3.0\lib\net462\System.Reflection.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.Reflection.dll'. Remove one of the duplicate references. [E:\agt01\ENS-EB577-BEQI\myProject\myProject.csproj]
26-Mar-2019 05:30:23 CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'E:\agt01\ENS-EB577-BEQI\Bin\Packages\System.IO.4.3.0\lib\net462\System.IO.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.IO.dll'. Remove one of the duplicate references. [E:\agt01\myProject-EB577-BEQI\myProject\myProject.csproj]
26-Mar-2019 05:30:23
26-Mar-2019 05:30:23 617 Warning(s)
26-Mar-2019 05:30:23 4 Error(s)
So basically bamboo is trying to pick those system dlls from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\
So to work that around, I have to make sure I remove these references from my csproj as nuget packages and push to bamboo in order to get a successful build but when testing in my local I have to add them as nuget packages to get things to work.
Has any one faced such issue before?

For the specific errors you included, it looks as though you have duplicate imports of the assemblies within your .csproj file. I would open up the myProject.csproj and pick either the ones in Bin\Packages or the System ones installed as part of the .Net Framework install.
I personally would go with the System installed ones that were put there as part of the framework install. If you are having issues finding those on the Bamboo agent, make sure that .NET Framework 4.6.2 is installed on the build agent in the specified location (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2)

ASP.NET web site builds locally, but throws MSB3268 on the build server

I added a project to my web site solution. Everything built fine locally and on the build server.
I added a line in web code to call a method in the new project. Everything built and worked fine locally, but it broke the build on the build server.
I got a pile of errors going something like this:
warning MSB3268: The primary reference "C:...\ProjectName.dll" could not be resolved because it has an indirect dependency on the framework assembly "Assembly.Name (e.g. System.Runtime)", Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.5". To resolve this problem, either remove the reference "C:...\ProjectName.dll" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
After all the warnings, the build failed with an error indicating the namespace ProjectName could not be found. Makes sense considering the project's dependencies couldn't be resolved.
At first I wondered if there was an issue with targeting the wrong framework. But there was a mix of 4.0 and 4.5 projects referenced by the 4.5 website. This was the first one that had failed.
The only difference between this and the other projects was that it referenced third-party DLLs. So apparently their dependencies are the ones that couldn't be resolved.

This post held the key: http://devsilos.blogspot.com/2014/10/msb3268-while-targeting-aspnet-web-site.html
The author suggests:
aspnet_compiler for some reason does not take into account the .dll-s that reside under the Facade directory of 4.5 assemblies (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\Facades).
It looks only under
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5
My extrapolation on that idea is that maybe the compiler doesn't take into account DDLs in the Facades directory if they're referenced by a third-party DLL rather than directly from your project.
The solution, as suggested by the author, was to find the DLLs matching assemblies mentioned in the MSB3268 warnings and copy them from Facades to its parent directory.
I think my problem/solution differed from the blog's in that it had nothing to do with the .NET Framework version targeted. It had only to do with whether the build server's compiler looked in the right places to resolve third-party DLLs' dependencies.
The problem caused about ten hours of frustration. I hope this helps someone else avoid that!

CryptoObfuscator error obfuscating UWP assembly

When trying to obfuscate a UWP (WinRT) AnyCPU assembly using CryptoObfuscator, the following error messages are observed:
1.) When merging in LogicNP.CryptoLicensing.WinRT.dll (a WinRT assembly) into a UWP DLL:
Error occurred while obfuscation: - .Net framework version type of the licensing assembly (Silverlight) does not match the version type of the obfuscating assembly (Normal).
2.) When merging of the licensing assembly is ignored:
Error occurred while obfuscation: System.IO.FileNotFoundException - System.IO.FileNotFoundException: could not result: System.Runtime, Version=4.0.20.0, Culture=neutral... Specify the path where this assembly resides using 'Search Directories'
Has anyone successfully used CryptoObfuscator (which is advertised as working on any .NET assembly) successfully?

There are in fact two issues to take into account when using CryptObfuscator in this scenario:
To obfuscate for other .NET versions, the following must be added to each relevant csproj in addition to setting the target framework to :
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
This resolves most can not find file issues when obfuscating.
For System.Runtime, you will need to download and open the NuGet package of System.Runtime. In the lib folder you will find some nice hacks that depend on the CLR in use and glue the rest of your .NET assemblies together with the CLR, such as using forwarded types for .NET 4.7. But in the ref folder such as for netstandard1.5 you will find a System.Runtime.dll. Copy that one manually to the output folder or a location where CryptoObfuscator will search.
You can also put it in another folder, and specify in CryptoObfuscator a search directory using Project Properties or in XML:
<SearchDirectories>
<SearchDirectory Path="PATH" />
</SearchDirectories>

Try Download from nuget "Microsoft.NETCore.UniversalWindowsPlatform" and copy "System.Runtime.dll" downloaded from nuget to CryptoObfuscator folder.

MSBuild can no longer find dependencies after upgrading from 4.0 to 4.5?

We have a .Net 3.5 application that is built using some scripts that call msbuild.exe
Recently all our machines started automatically updating from .Net 4.0 to .Net 4.5 as part of a company-wide policty, and our build scripts started failing.
The errors given is that they cannot find a referenced assembly, like this :
error CS0012: The type 'System.Drawing.Image' is defined in an assembly that is not referenced.
You must add a reference to assembly 'System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
It looks like in every case, we try to build project A that has a reference to project B, and project B has a reference to library X, and get an error that project A needs a reference to library X.
A temporary workaround is to uninstall 4.5, uninstall 4.0, then re-install 4.0, however this is time consuming and not practical in an environment where updates are often silent and automatic.
I've tried using the following msbuild switches already, with no luck
/toolsversion:3.5 - Exception about Func being undefined
/toolsversion:4.0 - Does not work because 4.5 replaced 4.0 tools
/p:TargetFrameworkVersion="v3.5" - Same error
/p:VisualStudioVersion=11.0 - Same error
*` in the csproj file - Already exists, and same error
The .csproj files already has <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> specified in every single csproj file in my solution, and ToolsVersion="4.0".
I have also tried changing the TargetFrameworkVersion to 4.0, and that does not work either.
I found some notes online about Microsoft changing the flag OnlyReferenceAndBuildProjectsEnabledInSolutionConfiguration from false to true during the 4.0 to 4.5 update, however manually setting that flag in the csproj files also does not fix the issue.
<OnlyReferenceAndBuildProjectsEnabledInSolutionConfiguration>
false
</OnlyReferenceAndBuildProjectsEnabledInSolutionConfiguration>
Why is msbuild failing to find these child assemblies after upgrading from 4.0 to 4.5, and how can I fix it?
Update
I've finally figured out the source of the problem, but I have no idea how this could be happening.
ProjectA has a class which inherits from an abstract class in ProjectB, and one of the properties of ProejctB.BaseClass is of type System.Drawing.Image.
namespace ProjectA
{
public class SomeClass : BaseClass { }
}
namespace ProjectB
{
public abstract class BaseClass
{
public System.Drawing.Image GetImage() { };
}
}
From everything I've read online, and from creating a test project of my own, this means that ProjectA needs a reference to System.Drawing.Image in order to build.
But for whatever reason, this restriction does not seem to matter for our project when buliding with msbuild 4.0 or in VS 2010. It's perfectly happy to build ProjectA without a reference to System.Drawing.Image.
Even after updating to .Net 4.5, I can still build ProjectA successfully from Visual Studio 2010 without adding a reference to System.Drawing.Image, however building using msbuild now (correctly?) fails. I also get the reference errors when building in VS 2012 Express, so whatever is allowing this to occur has apparently been fixed in newer versions of VS.
For now, I have gone through all 148 projects in our solution and fixed all the references, however I want to leave this question open to try and get an answer on why I am able to build ProjectA using msbuild 4.0 or Visual Studio 2010 without a reference to System.Drawing.Image.
I have already determined that I can't easily reproduce the behavior in a test project, so my best guess is its either some configuration, some part of the build scripts, or it's a bug that existed back when the .sln or .csproj files got created and no longer exists with newly created projects.

Based on Hans' comment, it sounds like something changed in the internal C# compiler between version 4 and version 5 to fix the bug that was allowing us to build ProjectA without proper references.
This doesn't have anything to do with MSBuild, what changed is that you are using a different C# compiler. Version 5 instead 4. I've seen cursory evidence in other questions that is is more aggressive about wanting to resolve indirect type references. Nothing to nail to the wall, everybody just fixes this with the obvious solution.
When viewing the msbuild.exe log, I can see it comes down to a call to csc.exe, which contains the exact same /reference list, however fails with 4.5.
Building ProjectA with 4.0
Task "Csc"
c:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE /reference:C:\Path\bin\Release\ProjectB.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.Services.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /debug:pdbonly /filealign:512 /keyfile:ProjectA.snk /optimize+ /out:obj\Release\ProjectA.dll /target:library Properties\AssemblyInfo.cs SomeFile.cs Properties\VersionInfo.cs
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.
Done executing task "Csc".
Building ProjectA with 4.5
Task "Csc" (TaskId:5812)
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn:4 /define:TRACE /highentropyva- /reference:C:\Path\bin\Release\ProjectB.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll" /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Web.Services.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /debug:pdbonly /filealign:512 /keyfile:ProjectA.snk /optimize+ /out:obj\Release\ProjectA.dll /target:library /utf8output Properties\AssemblyInfo.cs SomeFile.cs Properties\VersionInfo.cs (TaskId:5812)
Microsoft (R) Visual C# Compiler version 4.0.30319.18408 (TaskId:5812)
(TaskId:5812)
for Microsoft (R) .NET Framework 4.5 (TaskId:5812)
Copyright (C) Microsoft Corporation. All rights reserved. (TaskId:5812)
(TaskId:5812)
SomeFile.cs(32,18): error CS0012: The type 'System.Drawing.Image' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. [C:\Path\ProjectA.csproj]
c:\Path\bin\Release\ProjectB.dll: (Location of symbol related to previous error) (TaskId:5812)
The command exited with code 1. (TaskId:5812)
Done executing task "Csc" -- FAILED. (TaskId:5812)
I was hoping someone here would be able to explain what that was, and how I could reproduce this "bug" with 4.0, however it doesn't look like this question is an easy one to answer.

If I had to guess, I'm going to say that all the references that it can no longer locate are version 2.0.0.0. We had a similar issue here recently where we had to update the references to be for 4.0.0.0 versions of System.* and mscorlib and similar references.
If you cannot replace the references and BindingRedirects aren't an option, try adding v2.0.0.0 manually to your bin folder.
Lastly, you can make your build output verbose to see where it's looking for these references, it might guide you to find a solution.

Perhaps when it updates its not updating your Runtime Settings Schema, specifically the <probing> Element that tells .Net what paths to search for assemblies:
Eg.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
See: http://msdn.microsoft.com/en-us/library/microsoft.build.tasks.assignprojectconfiguration.onlyreferenceandbuildprojectsenabledinsolutionconfiguration%28v=vs.121%29.aspx

Rachel, any chance references on your System.Drawing on projects are set to SpecificVersion = true after the upgrade?
Also, are you using any precompiled resx files in your library projects?
Try right-clicking the .resx file and choosing 'Run Custom Tool' again to redo the references.
And for last of my attempts to help you, you could try using the useLegacyV2RuntimeActivationPolicy="true" on your main project configuration and try to use the legacy System.Drawing library.