Skip to content
This repository has been archived by the owner on Jan 12, 2024. It is now read-only.

Fix multiple build issues with VS2017 #162

Open
wants to merge 7 commits into
base: dev
Choose a base branch
from
Open

Fix multiple build issues with VS2017 #162

wants to merge 7 commits into from

Conversation

wjk
Copy link
Contributor

@wjk wjk commented Jun 30, 2018

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 the dev branch, 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!

wjk added 6 commits June 29, 2018 19:44
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 disagreed with me on whether or not this change was desirable.
Since he's the maintainer, his judgment takes precedence.

This reverts commit 7989aa3.
@wjk
Copy link
Contributor Author

wjk commented Jun 30, 2018

@kzu I've tried to track down the test failures, which are caused by a use of the nonexistent SkipNonexistentTargets property on the MSBuild MSBuild task. However, I cannot find this string anywhere in the test or product code. If you could give me some pointers as to what was causing this, I would be very appreciative. Thanks!

@kzu
Copy link
Contributor

kzu commented Jul 13, 2018

Hm. Might be an environment issue: OrchardCMS/OrchardCore#1523

@kzu
Copy link
Contributor

kzu commented Sep 4, 2018

Heya @wjk turns out that the failing tests are now fixed :)

#165

@@ -69,4 +69,6 @@ AssemblyVersion=$(AssemblyVersion)" />
<Copy SourceFiles="$(PackageTargetPath)" DestinationFolder="$(TEMP)\packages" />
</Target>

<Import Project="$(MSBuildProjectDirectory)\$(MSBuildProjectName).targets" Condition="Exists('$(MSBuildProjectDirectory)\$(MSBuildProjectName).targets')" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Brought this commit in #167

@@ -60,8 +60,6 @@ AssemblyVersion=$(AssemblyVersion)" />
</Target>

<Target Name="LocalPublish" Condition="'$(CI)' != 'true'" AfterTargets="Pack">
<Exec Command='rd "$(NuGetPackageRoot)$(PackageId.ToLowerInvariant())" /q /s' Condition="Exists('$(NuGetPackageRoot)$(PackageId.ToLowerInvariant())')" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants