Skip to content

[windows] fix for $(HOME) blank in some situations - #879

Merged
jonpryor merged 1 commit into
dotnet:masterfrom
jonathanpeppers:windows-home
Sep 20, 2017
Merged

[windows] fix for $(HOME) blank in some situations#879
jonpryor merged 1 commit into
dotnet:masterfrom
jonathanpeppers:windows-home

Conversation

@jonathanpeppers

Copy link
Copy Markdown
Member

When running the build under a VSTS build agent, $(HOME) was evaluated
to an empty string. $(USERPROFILE) seems to be a more reliable way to
retrieve the correct path on Windows.

Example here:
https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=1004861

When running the build under a VSTS build agent, `$(HOME)` was evaluated
to an empty string. `$(USERPROFILE)` seems to be a more reliable way to
retrieve the correct path on Windows.
Example here:
https://devdiv.visualstudio.com/DevDiv/_build/index?buildId=1004861
@dnfclas

Copy link
Copy Markdown

@jonathanpeppers,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@jonpryor
jonpryor merged commit 0267204 into dotnet:masterSep 20, 2017
@jonathanpeppers
jonathanpeppers deleted the windows-home branch September 25, 2017 13:14
jonpryor pushed a commit that referenced this pull request Sep 16, 2021
Fixes: #6271
Context: 2d81740
Context: #5749
Context: dotnet/java-interop@d16b1e5
Changes: dotnet/java-interop@f359e73...8f7ddcd
* dotnet/java-interop@8f7ddcdd: [build] Fix 'BuildVersionInfo_g_cs' build target. (#881)
* dotnet/java-interop@7068f4b2: [build] Enable string operations globalization code analyzers. (#879)
* dotnet/java-interop@3e6a6232: [build] Use GitInfo to Generate Version information. (#875)
In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also 2d81740.
This allows loading two different version of the "same" assembly, e.g.
`Java.Interop.Tools.Diagnostics.dll`, from two different filesystem
locations in the same AppDomain/AssemblyLoadContext.
However, strong-naming is only part of the solution. The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?
Multiple sub-modules have been updated to use the [`GitInfo`][0]
[NuGet Package][1] so that assembly versions are unique per-commit:
* `external/xamarin-android-tools`: 25c5cb5
* `.external` & `monodroid`: 2d81740
Update the `external/Java.Interop` submodule to follow suit.
This in turn requires updates to `xaprepare` and the CI YAML files to
ensure that `GitInfo` is configured correctly within Java.Interop.
[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
@github-actionsgithub-actionsBot locked and limited conversation to collaborators Feb 2, 2024
Sign up for freeto 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.

3 participants

@jonathanpeppers@dnfclas@jonpryor