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.

Nuget package not found after restore VS 2019 16.5.0

I've been fighting with nuget all morning, trying to get a solution that builds in the UI AND from the command line. Here's the latest problem, which I haven't made any headway on:
I'm running nuget restore on the solution file. This works, all referenced packages are restored - I can see the files in the /packages folder under the solution folder.
I'm building with devenv command line - I have to because this solution contains project types that msbuild doesn't support.
The first project that references a nuget package, fails to compile with ...cs(3,7,3,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
The project builds (and rebuilds, and rebuilds with the package folder cleared out) just fine in the UI, but the command line build isn't seeing the restored packages.
The build that's failing is in a CLEAN folder on the same computer where I'm doing the UI build, so it's get from source control, nuget restore, devenv build.
Things I've tried
Looking for bad hint paths in the project file (saw this in another question/answer). These references don't appear in the project file at all - trying to add them produces an error saying that the reference can't be added because it's already added automatically by the build system.
Verifying that files do exist after restore.
Doing the same steps from a command line in the SAME folder where the UI is building. This works fine.
What am I missing? this shouldn't be so hard..
UPDATE: The solution consists of 14 projects: 9 C# class libraries, 2 c# applications, 1 reporting services project and 2 WiX installer projects. All C# projects target Net472, NOT Core. The key part of the solution structure appears to be:
Project A references
Newtonsoft.Json via nuget
Project B references
Project A
Newtonsoft.Json via nuget
Other packages via nuget
During build, project B fails to compile due to the lack of a reference to Newtonsoft.Json. Project A and all of the other nuget packages are supplied to the compier as references. Again, all nuget packages are in fact restored - Project A finds Newtonsoft.Json, project B does not.
In the detailed msbuild log output, this is the only mention of Newtonsoft.Json in the build of project 10 (Project B above):
10> Dependency "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".
10> Resolved file path is "...ProjectA\bin\Release\Newtonsoft.Json.dll".
10> Reference found at search path location "...ProjectA\bin\Release".
10> For SearchPath "...ProjectA\bin\Release".
10> Considered "...ProjectA\bin\Release\Newtonsoft.Json.winmd", but it didn't exist.
10> Required by "...ProjectA\bin\Release\ProjectA.dll".
10> Required by "C:\...ProjectA2\bin\Release\ProjectA2.dll".
10> Found related file "...ProjectA\bin\Release\Newtonsoft.Json.xml".
10> The ImageRuntimeVersion for this reference is "v4.0.30319".
(Folder and project names have been obscured)

A couple things going on here, finally got a solution that works. Why this built in the IDE is anyone's guess - it's adding some extra secret sauce to make things work (more than just the automatic nuget restore).
I tried changing all projects to use PackageRef instead of packages.config. That caused nuget restore to fail with an obscure msbuild error that I didn't try to diagnose.
I noticed that SOME of the nuget packages were referenced in the .csproj files with ordinary Reference elements, but some of them were not (specifically, Newtonsoft.Json in "Project B" - and some others that I hadn't noticed due to B failing).
To correct the situation:
Remove ALL use of PackageRef elements - change back to packages.config in ALL projects
Make sure the each of the nuget -provided DLLs is referenced in the .csproj files. You have to do this by editing the csproj file by hand - the IDE won't let you add the missing references.
I'm assuming that this is a temporary situation and that in the long run the solution will be to use PackageReference everywhere.

you already checked the files app.config and packages.config, and the dotnet framework version?

Nuget package not found after restore VS 2019 16.5.0
devenv /build command line does not have the job to restore nuget packages by default. However, there are such options in VS IDE so that it will restore packages first and then build. But these do not work in command line.See this similar issue.
But you still want to use devenv to build your project and since you use a framework project with packages.config, I suggest you could use nuget.exe.See this.You can try these:
1) download nuget.exe from this link and then configure its local address to PATH in the environment variable and make sure that you can call nuget from CMD.
2) open vs command prompt, cd the path of the solution and then type this first:
nuget restore
Then you can type your devenv command line and I am sure that this will execute without any errors.
devenv xxxx.sln /rebuild
Besides,you can add a custom target in any xxx.csproj file of your solution like this:
<Target Name="restoresolution" BeforeTargets="BeforeBuild">
<PropertyGroup>
<nugetpath>C:\tools</nugetpath> /////the local path of the nuget.exe
</PropertyGroup>
<ItemGroup>
<slns Include="$(MSBuildProjectDirectory)\..\**\*.sln" />
</ItemGroup>
<Exec command="$(nugetpath)\nuget restore %(slns.Identity)" />
</Target>
Then you can run devenv xxxx.sln /rebuild directly.

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.

Nuget & dotnet on linux - using/package a provided package

perhaps Im getting old but Im really confused on how to use a nupkg on Linux. Resolving and installing dependencies/adding libs for C is easier for me (never would thought I would say so).
I got a package from a vendor (YYYYY_linux.3.0.77.nupkg) and want to run their example code (version for windows with visual studio worked out of the box) but they told me their linux pack would also work.
What I did:
dotnet init
... coding ...
dotnet restore
dotnet build
/home/tobiass/code/XXXX/Program.cs(27,11): error CS0246: The type or
namespace name 'YYYYY' could not be found (are you missing a using
directive or an assembly reference?)
Afterwards I tried two things:
1.
I edited NuGet.Config
dotnet restore
The nupkg shows up as a feed.
But I still get the same error.
2.
I also tried to create a local feed
mono nuget.exe add ../YYYYYYY_linux.3.0.77.nupkg -source ./
but it always results in
The requested feature is not implemented.
What is the correct way on Linux to add a library? Must it be also a part of project.json? Some config in .nuget?
Best,
Tobias

I suspect your project is not a .NET Core project so you should be using nuget.exe instead of dotnet.
So first I would take a look at the example code. Does it have a .csproj file? Does it have a packages.config file? Does it have a packages folder with the .nupkg file in it already? If so then nothing needs to be done and it should just compile.
From the error message one or more of the above are not correct. If the project file (.csproj) has references to the files in the NuGet package and there is an existing packages.config file then all you need to do is restore the package. To do that you need to put the NuGet package somewhere so it can be restored. You could simply just copy the .nupkg file into ~/.local/share/NuGet/Cache/ which is the machine cache for all NuGet packages and then restore it into the project by running nuget restore Path/To/YourSolution.sln.
If the project does not have a packages.config file then you would need to install it into the project. The simplest way would be to use MonoDevelop. That has built-in support for adding NuGet packages to projects.
Otherwise you could just unzip the .nupkg file and copy the files where they need to go into the solution's packages directory based on the information in the .csproj file.

Reference Microsoft.VisualStudio.QualityTools.UnitTestFramework for CI build

I have created a C# test project in VS2015 RC. it builds locally but when i attempt to build on our CI build server (TeamCity) it fails with errors:
UnitTest1.cs(2,17): error CS0234: The type or namespace name
'VisualStudio' does not exist in the namespace 'Microsoft' (are you
missing an assembly reference?)
[... .Tests.csproj]
UnitTest1.cs(9,10): error CS0246: The type or namespace name
'TestMethod' could not be found (are you missing a using directive or
an assembly reference?)
[... .Tests.csproj]
Clearly this is because the assembly containing these namespaces (Microsoft.VisualStudio.QualityTools.UnitTestFramework) is not on the build server; on my local machine it resides at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.
I could copy the assembly into my solution so that it becomes part of the codebase but manually moving files feels like a bit of an inelegant hack. I searched around on nuget and found http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ which I figured would do the trick, but installing that package failed with:
Install-Package : Could not install package
'Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1'.
You are trying to install this package into a project that targets
'.NETFramework, Version=v4.5.2', but the package does not contain any
assembly references or content files that are compatible with that
framework
What's my best option of solving this? I'm surprised that creating a test project in VS2015 does not automatically include all the dependencies that I need, though perhaps I'm being naive (I'm something of a fledgling dot netter).

The answer is similar to option 1 in eng.augusto's answer.
Microsoft doesn't provide NuGet for the latest version of Microsoft.VisualStudio.QualityTools.UnitTestFramework,
but rather supplies it as a part of Visual Studio
(normally at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)
I created the folder Microsoft.VisualStudio.QualityTools as a subfolder of my solution and copied:
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml
The files should be added to source control (even if DLLs are usually ignored).
Then I changed references in my Test.csproj to refer to a new location.

Hmm I have some ideas, so choose the one that best fits your needs
A simple answer should be mark the DLL to copy local and use a folder like Assemblies in the same folder of the solution and references "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"
Install Visual Studio in your build server. Sounds nuts but it's the closest to "developer machine" that you have.
Install the DLL in the GAC so you don't have to bother with this.
Fix the NuGet package (Adding a reference for the .NET Framework version) and use it.
Downgrade your .NET Framework version so you can use the NuGet package.
Create your own NuGet server! (and add the reference of the DLLs you need).
IMHO I'd choose the first answer, because it seems to be the "best way" to use NuGet to resolve all your packages problems but you are using a DLL that you don't know if it should be trusted.
In system used in "old" languages like C, or C++ it's common you download the source code and the libraries needed for the code to run so I do not think the NuGet package it's the best solution.
Using the first option you always have the same version and could check the MD5 of the file and know exactly what is running in your build server.
Maybe the real best option should be 6. When you use your own NuGet server to handle your DLLs making your live more awesome and trustable.

For projects created in VS 2017. Adding Nuget package Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated allows to build unit test projects on CI without VS installed on build server:

I was having this issue when trying to use MSBuild on our dev server via our CI/CD process after I was asked to uninstall VS2013 from our dev server by our IT team.
In my case in my build output there were a few lines with the word Considered. What this means is that the build is considering those folders for locations where the file may be located. One of those lines was as follows:
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
I copied Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll from my local machine to that folder on the dev server and the error went away.

Of course Microsoft does a s...t job. To fix this, you need to copy the dll's to some convinint lication and reference them from your ptoject .csproj file.
<HintPath>..\packages\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Reference Include="QualityTools-Fakes">
<HintPath>..\packages\Microsoft.QualityTools.Testing.Fakes.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
I don't understand why when we add this from VSudio it does not update the same file instead no one has an idea what it does. In Java you have a single file pom.xml or build.gradle, nothing else. In C# there is all sorts of stuff which adds no value but confusion.