We have a project that requires a pre-build task - signing a DLL without source code. For this, we're using Brutal Dev StrongNameSigner, which works well.
Recently, we've added this package from nuget - this adds an entry in the csproj such as the following:
<Import Project="..\packages\Brutal.Dev.StrongNameSigner.2.1.3\build\Brutal.Dev.StrongNameSigner.targets" Condition="Exists('..\packages\Brutal.Dev.StrongNameSigner.2.1.3\build\Brutal.Dev.StrongNameSigner.targets')" />
That line picks up information such as environment variables needed for compilation. Unfortunately, that line also breaks all our project references, such as below:
I've checked their properties; it's all empty.
Removing the Import line will cause all the DLLs to show up correctly, but fail to build due to missing environment variables.
Oddly enough, it seems that the project still builds!
Thanks
Related
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.
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
Disclaimer, I am creating the Nuget in question.
I am currently in the process of creating a Nuget package for Xamarin Forms, which has been going great. Here is the repo. I have gotten it fully working no issues.
I have also been testing it by including it as a project reference in another, closed source, repo. And this has also been working perfectly fine.
However, I decided to switch from using the project reference to using the actual Nuget, since I was no longer tinkering with the code on the fly to make it work correctly, and I have hit a wall.
The moment I include the package, I am given upward of 5000 errors, which are either
(/Users/UserHere/Projects/PopupsError/PopupsError.Android/CSC: Error CS1703: Multiple assemblies with equivalent identity have been imported: /Users/UserHere/.nuget/packages/awaitablepopups/0.2.5/lib/netstandard2.0/System.Xml.XmlSerializer.dll' and /Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/Facades/System.Xml.XmlSerializer.dll. Remove one of the duplicate references. (CS1703) (PopupsError.Android))
or
(/Users/UserHere/Projects/PopupsError/PopupsError.Android/Resources/Resource.designer.cs(36,36): Error CS0731: The type forwarder for type 'System.Attribute' in assembly 'netstandard' causes a cycle (CS0731) (PopupsError.Android))
And a multitude of others, I have a completely fresh repo with just the Nuget added here
The bit that is most confusing to me, is that the same exact project works as a project reference, but if I make it a Nuget and add it in, then it throws the error seen above.
I am under the impression, that its some small option I could add, but after some research, I am unable to figure out what small option I should tick. Any help would be greatly appreciated
This is sometimes headache.
For local projects migrating from packages.config to PackageReference
You have to go and delete duplicate nuget from physical disk.
Delete this folder /Users/UserHere/.nuget/packages/awaitablepopups/0.2.5/lib/netstandard2.0
Since you mentioned you moved from packages.config to PackageReference within csproj file, you have to be also careful that csproj still doesnt have old style imports , you can fix this by comparing your csproj file with newly created project csproj file as reference.
Delete and remove "package.config" and 'app.config` reference from csproj file as well.
Update
For NuGet
Check .nuspec file and remove reduntant imports
Clean the project , delete bin obj folders manually as well.
Remove NuGet.Build.Packaging , its not required. Its adding all of those reduntant assemblies.
My csproj has the following lines:
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<PropertyGroup>
<Deterministic>False</Deterministic>
<ItemGroup>
<ProjectReference Include="..\blah.Common\blah.Common.csproj" />
<ProjectReference Include="..\blah.Model\blah.Model.csproj" />
</ItemGroup>
The referenced projects build fine. However in the VS tree these two projects randomly disappear from the Dependencies tree and VS reports the references as missing and the build passes.
Reloading/rebuilding/cleaning/restarting/removing then adding the projects again in no particular order usually fixes it. Problem comes back after a legitimate build error crops up in another project.
I am using Resharper and VS2017
I have tried dotnet restore with no luck. Any ideas why this one particular project is constantly losing its references?
Edit: I just realised I incorrectly mentioned the build as FAILING. It does not fail and builds successfully, however my project is litered with red errors and warnings saying references are missing. After a successful build the red warnings/errors disappear then randomly come back again.
Sometimes the projects are literally missing from the references tree, other times they are visible. When right clicking "add reference" the project is already ticked however. Unloading the project and reloading or doing a full rebuild fixes the "Error" only for it to come back at some point.
Even though the "Error List" is filled with missing reference errors, a clean and full build produces no errors and creates a successful build.
Did you check the .NET framework version that these 3 projects are targeting?
Incompatibility between framework versions allows the reference to get added but results in missing references during build/run time. To validate if this is indeed the problem, you can check the warnings that Visual Studio produces while building the solution. An alternative way of finding the root cause of the problem, would be to add one of the projects as a DLL reference while keeping the other as a project reference. If the DLL reference doesn't work, it means there is some configuration mismatch between the source and target projects (e.g. .NET framework version). If the DLL version works, then it means Project References are broken, in which case you can check if path provided is correct.
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.