We Keep Coding

Using MSBuild at command-line to produce VSIX does not error, does not build VSIX - but IDE does. How to debug?

I have a VSIX extension which I have migrated to a new solution (basically to remove older projects targeting older VS versions no longer supported by my company) and to simplify the codebase for ease of maintenance.
Within the IDE, it does not matter if I set the active configuration to Debug|x86 or Release|x86, it will build a VSIX artifact OK. All good so far.
If I use
MSBuuild /t:Build /p:Configuration=Release /p:Platform=x86 -restore -detailedSummary MyExtension.sln
it will build without any errors, but no VSIX is produced.
I have poured over the terminal output and there are no warnings/errors and the DLL output of projects in the solution are produced.
I did read the following:
Project not selected to build for this solution configuration
The option to click deploy from the above link is not available for my VSIX - all the deploy options are disabled.
I have searched S.O. for similar issues regarding a VSIX not being produced, but none seem apt.
How should I debug this? What is different about a command-line MSBuild from the in-IDE build? Hopefully somebody has had a similar experience and can let me know what was causal for them, so that I can give something a try.
Update 1:
It transpired that although I was targeting .NET Framework 4.6, some .csproj references copied over from the migrated project had entries for net472, despite NuGet packages themselves being selected for compatibility with .NET Framework 4.6.
I had to manually edit a few .csproj files. There were some reference issues in associated projects that then needed fixing.
The residual issue now is as follows:
The in-IDE build fails with a single error...
A PackageReference to Microsoft.Build.* without ExcludeAssets="runtime" exists in your project. This will cause MSBuild assemblies to be copied to your output directory, causing your application to load them at runtime. To use the copy of MSBuild registered by MSBuildLocator, set ExcludeAssets="runtime" on the MSBuild PackageReferences. To disable this check, set the property DisableMSBuildAssemblyCopyCheck=true in your project file (not recommended as you must distributed all of MSBuild + associated toolset). Package(s) referenced: Microsoft.Build.Framework
So I grepped my source code folder for <PackageReference Include="Microsoft.Build and only a single project was in the result list. When I checked this project file, the entry in question did have ExcludeAssets="runtime" so I am unsure why the error is reported. I have tried project cleans followed by rebuild, or deleting bin and obj folders before building, to no avail.
I guess my question now is whether <Package Include="Microsoft.Build are relevant, since these are not <ReferencePackage Include elements as mentioned in the error message.
Update 2:
I hang my head in shame. PBKAC regarding Update 1 error. I had sent a copy of the code to a build engineer who committed it to a branch in our VCS. I then cloned this branch to a different location, and copy+pasted my more recent changes over the top. However, the grep tool (AstroGrep) I was using was still pointing at the older location not in the VCS. The older location contained package references with ExcludeAssets="runtime" as required. However, the newer location did not. Once I noticed this, I corrected it by editing the faulty .csproj file and the error from Update 1 went away.
However, I still appear to have the original issue the question is about.
I am awaiting my company's security team to approve the use of MSBuildLog so that I can get more detail and hopefully find the cause.
One other commenter suggest moving to solution PackageReference build rather than using packages.config. There is a question as to why this is needed. I am aware this seems like it could create a significant amount of extra work due to: this for which there are workarounds, but the commenter mentioned a "need" to use NuGet this way, when I think it is optional. I wish to understand more before committing to such a change.

Unfortunately, this is one of those things where it's a case of user beware.
When using NuGet, it is possible for it to appear to have succeeded in updating a NuGet reference, but unless one checks the underlying packages.config meticulously, you may not be getting what you think.
As I am migrating a solution that used packages.config instead of <Project Reference .../> elements in .csproj files, I have been caught out by IDE default behaviour changes.
NuGet seems to update the .csproj using <PacakageReference.../> elements by default. But this does not amend the packages.config entries that may already exist. As such, I ended up with a mish-mash that MSBuild seemed confused about at build time. Rather than throw an error, it just did not build what was expected.
The old packages.config files had entries targeting .NET Framework of net472 in some cases. I was adding NuGet references to earlier versions for net46 since this is what I need to target now, and this resulted in the problem behaviour, since any unchanged net472 entries were no good for producing the build output.
Since the project needs to support VS2015 also, I need to rely on packages.config approach and not <PackageReference.../> approach, which was not updating older references in the expected way.
As such, I had to remove the NuGet <PacakgeReference.../> and re-introduce correct package versions in packages.config. Once these were all correct, the VSIX built OK.

Visual Studio holding onto references that have been removed?

I get this as a warning when I build the solution. The weird part is that I removed those references long ago when I realized I didn't need them.
"Found conflicts between different versions of "System.Somenamespace.AnotherNamespace" that could not be resolved
I tried a Clean Solution then rebuild but no difference. I checked the solution and project files as well to see if there was a leftover reference but nothing. How do I clean this up?
Note: this is VS2017

Make sure nuget packages you use do not have discrepancies in their version. if so, you will either need to do assembly rebinding or use the exact same version across the solution. You can use the later by means of the “Consolidate” of the nuget package manager at the solution level.

Why can't Visual Studio find this nuget package's .props file?

Due to some git project changes, when I try to build, I get an error:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\MSTest.TestAdapter.1.1.11\build\net45\MSTest.TestAdapter.props.
The references to the project contain four missing references, two of which Microsoft.VisualStudio.TestPlatform.TestFramework, and Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions which seem to be related.
The other two, in case it proves to be relevant are System, and System.Core, but they aren't causing any problems... which is weird, cause I'm definately using them.
That missing file, the one from the error message, is absolutely there.
I've tried to uninstall and reinstall both packages, but nothing seems to help.

Open the projects .csproj file with your favourite text editor and delete any references to
MSTest.TestAdapter.props.
Edit: This is safe to do so, all that happened is that you have removed the DLL but for one reason or another your project file still references it as a dependency.

I would modify #JoshuaDuxbury's answer to say: you need to clean out obsolete references to MSTest.TestAdapter.props.
In my case, I had just updated the MSTest.TestAdapter NuGet fronm 1.3.2 to 2.0.0, but apparently when I did that, Visual Studio didn't clean up my .csproj file perfectly.
So, I had to delete the superflous MSTest.TestAdapter.props highlighted in two places:
Near the top of the project file:
...and again at the bottom of the file:
Once I did that, my CI pipeline was able to build everything correctly again.
Some of you with sharp eyes may notice something funny w/the 1.3.2 of MSTest.TestAdapter shown above: it seems the path to the packages folder is off! But that would be a topic for a different thread (or maybe an alternate explanation to why your build pipeline is unhappy.. maybe just fix your path to packages).

My issue didn't occur on my development box but on the Azure Build Pipeline. I removed the offending props files as per the other answers but to no avail. Ultimately I had to add the Nuget restore step to my the Azure build pipeline and move it to the proper slot before the building:

I have no idea how I've done it but I've had the same error and I thought the files were here but they actually weren't... so anyone who has this issue double check the paths.
In my case the Packages folder was at the same level as the project file however it was looking for files in the parent directory. Nuget restore and Update-Package -reinstall
were not fixing anything.

How to resolve? Assuming assembly reference 'System.Web.Mvc

With reference to questions/26393157/windows-update-caused-mvc3-and-mvc4-stop-working. The quickest way to resolve the warning below?
Assuming assembly reference 'System.Web.Mvc, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' matches
'System.Web.Mvc, Version=4.0.0.1, Culture=neutral,
PublicKeyToken=31bf3856ad364e35', you may need to supply runtime
policy.

I've had this happen with my NuGet packages every once in a while. I haven't been able to identify exactly how it happens. (I assume user error.)
I didn't need to upgrade anything to solve it, just clear the NuGet cache:
I use the nuget command line tool found here.
You can clear all caches with this command:
nuget locals all -clear
See: https://docs.nuget.org/consume/command-line-reference
You'll probably need to restart Visual Studio if it is open.

As per the best answer to the question....
Update MVC package (Visual Studio > Right click project/solution > manage nuget packages > Updates > Microsoft ASP.NET MVC > Update)
Manually add the compilation assembly
but then
Find - System.Web.Mvc, Version=4.0.0.0
and replace with - System.Web.Mvc, Version=4.0.0.1
Which will find all the hidden references in the Views/Web.config files.

Every time I have had this issue I always start by doing a rebuild which will clear your bin folder. You likely do not need to close and open visual studio, as I never have, and it should work.
If this doesn't work then try more complicated solutions like those above but this could be a quick, clean fix.

I was getting this warning in RoslynPad because one of the dll's I was referencing (for me it was mscorlib.dll) used a different version than the retrieved version via NuGet. As the warning states, you can solve it with solve it with a runtime policy with a link to the dll of the version you want to be using. Just add something like this to the top of your file:
#r "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll"

Sorry for the late reply but in my case this warning was showing up because I was using different versions of Microsoft.AspNet.Mvc across my Visual Studio solution. I was able to get rid of it by upgrading the older packages to the same version.
Hope this helps someone.

What worked for me after trying severally is to update application insights and all packages from NuGet. Then I ensured that there were no version conflicts on the App insights and it worked fine.

Don't refer NuGet Package Components and interfaces directly from your cshtml code. Instead, write your own components, extesion methods and view models referencing them from plain C# code placed in cs files. First, then you wouldn't obtain CS1702 warning. And secondly, this will facilitate future migrations to newer versions of the NuGet package or even another package: All necessary fixes will be shown you by the compiler.
This is probably the desired change in your run-time policy.

After tested all propositions, I finally succeeded to get rid of the warning by editing the .csproj of my web application and set the property MvcBuildViews to false.
Maybe this could help some of you.

Error: Reference to type claims it is defined, but it could not be found

I have a solution with 3 projects:
ParsersBase, that defines an interface IParseRule
ParsersLibrary, that has a reference to ParsersBase and defines a class HtmlImageUrlParseRule : IParseRule
ParsersLibraryTest, that has a reference to ParsersBase and ParsersLibrary and defines a test class with some test methods
When I'm trying to build it, I get a warning:
Reference to type 'AVSoft.ParsersBase.IParseRule' claims it is defined in 'c:\Users\Tim\Dropbox\projects\Image Downloader\ParsersLibrary\bin\Debug\ParsersLibrary.dll', but it could not be found
Why is VS trying to find AVSoft.ParsersBase.IParseRule in ParsersLibrary.dll? ParsersLibraryTest has a reference to ParsersBase; it just doesn't make any sense.

Another way this could happen is if you're using several NuGet packages where one, probably central, package has been updated but some additional functionality packages haven't been.
To work through my recent example - the error was "Reference to type 'ConsumerSubscriptionConfigurator<>' claims it is defined in 'MassTransit', but it could not be found". This is because we had updated MassTransit from 2 to 3, but we had not updated some of the other optional packages (MassTransit.log4net and MassTransit.Autofac) to the same version number. It appears as if assembly redirection had kept everything working until we tried to use one more additional feature.

This error seems to cover a variety of scenarios. In my case, closing and re-opening Visual Studio was the trick. After restarting Visual Studio, I was able to build the project as expected.

I had a similar problem. The site was running a cached version of the dll and not the one I had deployed to the bin directory. I cleared the temporary asp.net folder contents and this solved the issue.

It was my fault, I had a ParsersLibrary project at the start and then renamed it to ParsersBase, but I didn't rename an assembly name, then I added a ParsersLibrary project again.
So, two projects had the same assembly name and it's not very good, is it? :) Assemblies overlap each other, so I have this error.

I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. The problem was following: my solution had Target Framework = 3.5 and I added a reference to Microsoft.Practices.Prism v 4.0 which is built against the framework 4.0.
After changing target framework to 4.0 it worked

It looks like things are a bit easier now than they were before.
As other answer(s) have basically already stated, this error can result from an older version of the same NuGet package not having some of the newer types in it. While in production, this is generally managed through proper versioning, in development, you may end up reusing the same version number when making changes. And that's a likely place where this problem can arise.
To fix this, you can often just clear the cache by doing the following:
In Visual Studio, go to Tools > NuGet Package Manager > Package Manager Settings.
In the pop-up menu, navigate to NuGet Package Manager > General.
In the options on the right, click Clear All NuGet Cache(s).

I hit this exception today. The problem in my case was I had some.package v2.1installed in my host and some.package v2.3 installed in other projects. Update-Package on the host project to v2.3 fixed the issue.

I my case, I tried to test a WPF project with a .NET Core (3.1) test project which could not reference the needed WindowsBase.dll.

Updating/consolidating packages didn't help. Even a clean repo and a restart of Visual Studio didn't solve it for for me.
But rebooting did fix the problem!

#binki's comment helped me;
deleting all .vs, bin, and obj folders, and then reopening the project

ParsersLibraryTest needs to reference ParsersBase. The second part of the error should read "You must add a reference to assembly 'ParsersBase..."

I tried all of the above answers but none resolved my issue.
In the end, I checked in my latest code (GIT), then recloned the repository in a different location.
Not ideal, but at least problem solved.

I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. I have a lib of .Net 4 that was referenced by a .Net 3.5 program. After upgrading both to 4.61 it worked.
Seems like Func<T> is missing in .Net 3.5 and just upgrading that sample app would have been enough.
Further exp: Someone had added a signature in the library project (.Net 4) that uses a Func<T> parameter. But the sample program (3.5) already existed and ran fine so far. But at time of recompilation a dependency of a dependency clashed. Because mscorelib-3.5 had been already loaded. All happens at compilation time.

The only way I could overcome this error was to force uninstall of all nuget packages related and then reinstalling them. Sad but true.

I've just struggled with this error for a while now and finally get around it.
This is how to re-produce it and how I fixed it.
The problem was:
The packages were referenced by Right clicked -> add refernece -> Browse (choose). Then were added again as NuGet packages.
The solution was:
Remove the added references.
Remove the installed packages from .csproj.
Re-install the required packages from NuGet package mangager.
Close Visual Studio and re-open it.
Clean Project.
Build Project.
Note: If you couldn't remove the referenced files (no Remove option on right click) try close Visual studio and re-open it. Or delete or move the dll that were referenced then try again.

For me, I had chosen incorrect project, I was creating a class library project, I had to chose "Class Library (.Net framework)" but I had chosen "Class Library (.Net standard)"
Replacing the same resolved the issue.

The problem was following: my solution had Target Framework = 3.1 and I added a reference to Microsoft.EntityFrameworkCore.SqlServer v 2.0 which is built against the framework .

I had this problem with one of my library projects inside of a solution, after I switched from .NET Framework to .NET Standard. Eventually I just removed the project reference and added it again inside the application project that was reporting the problem. Oddly enough, the only thing that changed was project GUID switching to lower case from the previous upper case.