Conversation
On my machine, the old versions caused strange errors, complaining of non-overridden abstract methods (I think). Works now, though.
This line caused every NuGet.Build.Packages.Tasks build after the first to fail, because it deleted the files needed to build the package a second time.
This changes fixes an issue where the PackOnBuild property is not respected, because the BuildDependsOn property is set too soon, and is then overwritten with the default values in MSBuild. This only affects projects build as part of this solution.
This change is an addendum to 46736e2, which started failing again for some strange reason. VSLangProj150 was not bumped, because doing so caused class-not-found compilation errors.
|
@kzu I've tried to track down the test failures, which are caused by a use of the nonexistent |
|
Hm. Might be an environment issue: OrchardCMS/OrchardCore#1523 |
| <Copy SourceFiles="$(PackageTargetPath)" DestinationFolder="$(TEMP)\packages" /> | ||
| </Target> | ||
|
|
||
| <Import Project="$(MSBuildProjectDirectory)\$(MSBuildProjectName).targets" Condition="Exists('$(MSBuildProjectDirectory)\$(MSBuildProjectName).targets')" /> |
| </Target> | ||
|
|
||
| <Target Name="LocalPublish" Condition="'$(CI)' != 'true'" AfterTargets="Pack"> | ||
| <Exec Command='rd "$(NuGetPackageRoot)$(PackageId.ToLowerInvariant())" /q /s' Condition="Exists('$(NuGetPackageRoot)$(PackageId.ToLowerInvariant())')" /> |
There was a problem hiding this comment.
This clears the local nuget cache for the package we're building. Without this, testing locally is harder unnecessarily. i.e. you can have a test project referencing version * and since there will be nothing on the cache and the package in $(TEMP)\packages will be greater than the one in nuget, you'll automatically get that. If there was a cached version of a previous build of the same package version, removing this line will cause the old one to be used, instead of extracting the new build fresh.
2 participants
This PR does mostly what the title says. With the changes in this PR applied, nugetizer should build using
build.cmd /package, unmodified, on a computer with VS2017 installed. (When I tried building thedevbranch, I ran into numerous build errors which this PR fixes.) I filed #161 before realizing that the changes would be more involved than simply bumping NuGet package versions, so I created a PR from a different branch to note the increase in scope. Thanks!