[msbuild/tests] add test for custom framework setup via NuGet package. #1992
Conversation
atsushieno
force-pushed
the
custom-framework-test
branch
2 times, most recently
from
e9cd2ff to
05e8b1b
Compare
|
There is a problem in the package; it bundles both v9.0 and v1.0 assemblies, but v1.0 contains mscorlib.dll which should not be separate from the mono runtime. When we build apks, then it will result in inconsistent runtime and BCLs, which could work depending on how fresh the package is and in sync with the runtime in xamarin-android, but more likely could not (due to version mismatch between mono runtime and mscorlib). The fix should be either to get around TargetFrameworkRootPath limitation, or dump this idea. |
|
"The perfect is the enemy of the good." In some ways I'd prefer that we figure out how to not have the How "perfect" does this need to be, when most of this PR is about updating our unit test infrastructure to support such a NuGet package... I'm inclined to take this PR as-is. |
| public IList<Import> Imports { get; private set; } | ||
| public IList<Import> ImportsPrepended { get; private set; } | ||
| public IList<Import> ImportsAppended { get; private set; } | ||
| [Obsolete ("Use PostImports")] |
There was a problem hiding this comment.
PostImports does not exist.. should it be ImportsAppended ?
| @@ -157,6 +161,15 @@ public virtual List<ProjectResource> Save (bool saveProject = true) | |||
| }); | |||
| } | |||
|
|
|||
| Func<Import,ProjectResource> create_import_reference = import => new ProjectResource () { | |||
There was a problem hiding this comment.
@jonpryor should this be a local function? Do we prefer that other a normal method now?
|
This PR is not sufficient to prove my ideal concept actually works, but it is rather because my nuget package is bogus and shouldn't be used. A "good" PR would look almost identical, but to get such a package we need some working solution for custom framework setup. This is not what works now. The idea of giving additional framework directory was almost identical to what I showed at #1880 (there is a diff on the issue comment), but msbuild somehow did not resolve multiple framework paths to the expected one I specified when msbuild resolves TargetFrameworkRootPath. That's the blocker. |
It proves incomplete but kind of working solution for dotnet#1880 . The original idea (and what once worked) was to only extend an MSBuild property for ResolveSdks task. But after a couple of changes it does not work anymore, as there had been a handful of SDK resolution changes. Since it's not really safe to depend on those properties, we should rather provide a complete set of framework assemblies (which means, packages containing both v1.0 and latest) to get app still build.
atsushieno
force-pushed
the
custom-framework-test
branch
from
05e8b1b to
7209646
Compare
|
There seems still a way to get custom framework assembly referenced and build as expected, but is hacky and likely fragile - by having explicit HintPath to Mono.Android.dll. This means mono.android.jar will be resolved from the framework path, which means inconsistent with Mono.Android.dll. At this state this is all what I can do. |
It proves incomplete but kind of working solution for #1880 .
The original idea (and what once worked) was to only extend an MSBuild
property for ResolveSdks task. But after a couple of changes it does not
work anymore, as there had been a handful of SDK resolution changes.
Since it's not really safe to depend on those properties, we should rather
provide a complete set of framework assemblies (which means, packages
containing both v1.0 and latest) to get app still build.