Open bgavrilMS opened 5 years ago
I'll look into this when I can, but in general, I would not suggest making sign as part of the build step. I'd have build/pack do just that, then send the nuget to the signing mechanism once built (you can always extract/repack the nuget with zip before the nuget itself is signed).
Having similar problem here.
Can't run a Target\Task
from a .targets
inherited from a PackageReference
before GenerateNuspec
like this
<Target Name="ForceCall" BeforeTargets="GenerateNuspec">
<CallTarget Targets="TheTask" />
</Target>
I guess the .targets
isn't available at that point. (It's working fine if I hook it during build, like AfterTargets="CoreCompile"
+ working if the .targets
is part of the project)
This is why I used dotnet pack instead (it respects the nobuild). I did test this last week, and the problem seems solved?
The scripts I use are here:
Will investigate to make sure that references are not being rebuild.
I am using the preview versions of VS, but msbuild with nobuild & pack no longer seems to build reference assemblies (and thus overriding the signed assemblies).
Add a reference assembly to a project, like described in the blog (e.g. https://github.com/AzureAD/microsoft-authentication-library-for-dotnet)
Build the sln, which builds both project and ref project
Pack via "msbuild /t:pack /p:nobuild=true"
Actual: The pack does not obey the "nobuild" setting. It needs to rebuild because the ref assemblies are not actually produced in step 2
Expected: Pack should not rebuild
Impact: Because pack rebuilds, some DLLs are overwritten. This makes DLL signing difficult. Ideally all DLLs should be on disk and /t:pack just packs
Workaround: I can workaround by packing twice. So my release pipeline looks like this: