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.

Debugging .net core 3.1 library code published on github private nuget repository is broken?

In the last few days I've battled against an issue with debugging nuget packages that I still wasn't able to solve the way I want.
All this has been tested with visual studio 2022, updated to the latest version available.
We have a .NET 3.1 library published on github (private package).
We consume such library in many .NET 3.1 WebAPI backends that we develop.
We need to be able to debug such library.
GitHUB doesn't seem to support symbol servers at the moment, so I thought we had these 2 possibilities:
embed the pdb in the dll: this seemed the most straightforward solution and was the first I tried. By doing so on the core library, when we import that in a .NET webapi project and inspect the "modules" window, we can see that symbols for the dll have been loaded correctly; symbol file column reads: "OurLibrary.dll (embedded)"
include the pdb in the nupkg and then add a piece of code (found here https://github.com/dotnet/sdk/issues/1458#issuecomment-420456386) in the .csproj of consuming .NET webapi project that ensures that the dll pdb, contained in the nuget package, is copied to the bin folder. Also in this case, inspecting the modules window, it looks that the symbols have been loaded from metadata (which I guess is the pdb file itself).
STILL, in both cases, if the project is running, when I try to set a breakpoint in the Startup.cs file of the consuming WebAPI project, and step into an IServiceCollection extension method, which is defined in the library, I'm able to do so, but many symbols used in that file (referring to PUBLIC types defined in the library, or from the framework itself) are white, and I can't explore them by doing "go to definintion".
Instead, if I try to peek at the source code of the extension method mentioned before, when the project is not running, I'm able to peek at code by doing "go to definition" without issues. So, I set a breakpoint..
Then, when I launch the project:
you can see that it's a different "SessionFactory" file, and all the symbols have become white. If I try to go back to the original file (with all the types correctly resolved by intellisense), and set a breakpoint inside it, visual studio automatically switches to the other file (with "broken" intellisense) and sets the breakpoint there, which is very frustrating..
At the moment the only solution that really behaves the way I want requires me to remove the library nuget package from the project and reference the library as an "Existing project" inside the solution. By doing so everything works perfectly (of course, now library source code is part of the project) but of course seems wrong / time consuming / error prone.
Somebody is able to shed some light on what is going on? Thanks
EDIT: FURTHER DETAILS FOR USER #Transformer
I tried your suggestion to include the supplied code in .csproj of both the library and the consuming application:
By doing so in the library .csproj, it contains these settings related to PDB generation, in a property group:
<EmbedAllSources>true</EmbedAllSources>
<DebugSymbols>true</DebugSymbols>
<DebugType>portable</DebugType>
<AllowedReferenceRelatedFileExtensions>.pdb</AllowedReferenceRelatedFileExtensions>
<GeneratePackageOnBuild>True</GeneratePackageOnBuild>
It also includes this, outside of the property group:
<Target Name="AddReferenceRelatedPathsToCopyLocal" AfterTargets="ResolveAssemblyReferences">
<ItemGroup>
<ReferenceCopyLocalPaths Include="#(_ReferenceRelatedPaths)" />
</ItemGroup>
</Target>
Unfortunately, by doing so, the pdb doesn't seem to be included in the nupkg. Instead, if I add the following (a setting I've already found in the past):
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
then the pdb is included in nupkg, but still, I experience the same debugging problem in the consuming library, even if I add the code you supplied to the consuming library as well...any other idea?
Thanks a lot for your kind help

The issue is probably because the nuget packages are built with Release configuration which optimizes out the symbols. One way you can debug the package itself is if you open the project (from which you deploy the nuget), build it with Debug configuration, then copy the dll and pdb file into the bin\Debug\ folder of your consumer app. Then start the consumer app with no debugger attached, after it starts, you can attach your nuget project to that process, and your nuget code breakpoints will be hit.

Hello, from what I can see - that's because the embedded files are not copied to local, please try this in your cs.proj file and paste your comments
<PropertyGroup>
<AllowedReferenceRelatedFileExtensions>.pdb</AllowedReferenceRelatedFileExtensions>
</PropertyGroup>
<Target Name="AddReferenceRelatedPathsToCopyLocal" AfterTargets="ResolveAssemblyReferences">
<ItemGroup>
<ReferenceCopyLocalPaths Include="#(_ReferenceRelatedPaths)" />
</ItemGroup>
</Target>
Question from Carlo Arnaboldi : Where does this go?
Update: These are settings that go into the .proj file.
You you to do this in your nuget pacakge && your consuming project to see the pdb for symbol debugging
Also delete you old pdbs - exist visual studio/code and then delete the bin and obj folders

Where to put the DLL in C# source?

I just built https://snowballstem.org 's C# port.
It makes a dll I can reference in my project
<ItemGroup>
<Reference Include="Snowball">
<HintPath>..\..\..\snowballstemmer.dll</HintPath>
</Reference>
</ItemGroup>
What's the best place to put that (and other such) dll so that my codebase remains well-structured and portable and other developers can join in development very easily after cloning it?

As mentioned in the comment by mason, for .NET project it recommended to references to NuGet packages. However if you, for some reason, need / like to keep the libraries you use in a repository, you can use a file structure like this:
1 YourSolutionName
1.1 src // sources
1.1.1 project 1
etc.
1.2 libs // libraries / dlls you reference
1.2.1 library1
etc.
1.3 docs // documentation
etc.

It is true, we really don't want to have dll references in our code repo, if possible. However, if the target project does not have a NuGet package then it's not really possible.
Assuming you have a project folder and a solution file outside of it, I would create another folder, called something like ThirdPartyDlls and chuck in there. You can then add a reference to it in your project, making sure you use a relative path to it. This can be changed in the project file if necessary.
If you use Git for your source control, you can force push dlls.
Now, I am not a fan of this method, but sometimes you just don't have an option.

Use local source code of NuGet package to debug and edit code

I have a solution with an application project (ASP.NET Core) and multiple library projects. I want to separate some of the library projects into a separate solution and turn them into NuGet packages.
With the libraries in the same solution I could of course simply edit something in a library, run the application and see how it works (and debug, if necessary).
However, when I turn the libraries into a NuGet package, the application references the packages from our private NuGet feed instead of the project file.
My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).

DNT (Dot Net Tools) does this. You can specify which packages to switch and where they are.
See the 'switch-to-packages' and 'switch-to-projects' command line switches.
Its a bit fiddley as (when I last tried) you had to create a config file that holds the mapping, and it seems to be easy to break the switching. But its something.
https://github.com/RicoSuter/DNT
I've not tried it, but maybe you can use it to switch to packages on a commit for the build server to work correctly? (Or to ensure the references are correct in source control?)

If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.
Once you install the nuget, no matter how many changes you make, it’s useless. The nuget installed at this time is the version you made before any changes. No matter how you change it, it is the previous version. The version stays at that timestamp, unless you repackage the project. Generate nupkg and update the nuget version.
So nuget is not a good choice for your situation, you should use ProjectReference.
Directly use the ProjectReference to reference two source projects, build at the same time, and get the changed parts at the same time.
ProjectReference could cross two different solutions.
Add this on the main project:
<ItemGroup>
<!--add any nuget project'csproj file like this to debug its source code-->
<ProjectReference Include="..\xxx\xxx.csproj">
</ProjectReference>
</ItemGroup>
If the proejct is out of the solution, you could directly use the full path of the nuget project's csproj to connect it.

I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.
This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.

MSBuild .NET project that will output existing assembly as it's result

I need to create csproj file that will be usable as project reference in VS2013 and will output prebuilt binary as it's "Build" result.
We use referenced projects for build, however company policy doesn't allow access to some of that projects for everyone. As a result projects need to be updated manually to make them build. This is really a major inconvenience when switching branches and when making edits to project files, so I want to create dummy project that will be bound to pre-built binaries as their "output" and will be placed instead of real projects.
EDIT: Moving that assembly to Nuget package is not an option for now since Nuget has some issues with dev flow (when you need to debug/test/develop package). I saw some VS extension that implements switching between Nuget package and local project which might solve this issue, but I'm not sure if it will be accepted and want to explore other options.
To be clear - the thing I want to avoid is editing project in any way, so that project can be built cleanly after pulling it from Git, and I don't have to clean it every time before commit.

I haven't properly tested it, but the solution seems really simple (if I understand the question properly).
Just add this to the existing .csproj, overriding the Build target to just give the path to the pre-built assembly.
<Target
Name="Build"
Returns="$(TargetPath)" />
This assumes the TargetPath property already defined, and it should automatically be if you're modifying the original .csproj. Otherwise just define it yourself in a <PropertyGroup> before the Build task.
Note that having TargetPath defined is important for the ProjectReferences in your own project to resolve.

How about having those restricted (binary only) projects reside in an internal Nuget package feed, so that Nuget can install the packages as needed, on build?