ReleaseNotesTask failed in vs2022 preview

[haraldsteinlechner]

VS loads version 7 of fsharp.core in preview version which seems to result in MissingMethodExceptions when accessing paket's releasenote parsing functionality

[haraldsteinlechner]

seems like aardvark.build is using aardvark.build to publish itself with correct version. my fix includes using a helper library, which is not packed when using dotnet pack. the generated package is always missing the lib, even though aardvark.build has a paket.template with type file.

[krauthaufen]

Maybe just run the entire code in a new AssemblyLoadContext (this way we should be sure that nothing is pre-loaded) how would an additional lib help here?

[haraldsteinlechner]

because the additional lib returns vanilla dotnet type (as opposed to f# list) - and it seemed to work in my repro case. packaging the thing was my problem then....

[haraldsteinlechner]

actually i first tried the appdomain approach, which seemed not to be available in netstandard 2.0 (depsite the docs saying the opposite). seems like AssemblyLoadContext could work also - https://gamedev.stackexchange.com/a/191579

[hyazinthh]

The new package requires FSharp.Core >= 6.0

Conflict detected:

• Dependencies file requested package FSharp.Core: >= 5.0
• Aardvark.Build 1.0.16 requested package FSharp.Core: >= 6.0

[haraldsteinlechner]

thanks. i unlisted the package however :/

[haraldsteinlechner]

the situation is still unclear.

• VS seems to (sometimes) load FSharp.Core (prerelease versions for example)
• aardvark.build uses fake.releasenotes
• the interface for reading releasenotes uses a type defined in f#.core
• the idea was to isolate the build from the environment using AppDomain or AssemblyLoadContext. Both do not work, since aardvark.build should be netstandard2.0

Anyhow, having a build plugin which references a lot of stuff is not robust for the future. Also having a build time dependency fixing dependencies to particular versions is bad. So everyhing should be "statically linked", which seems impossible to do in a robust way:

• Linking FSharp.Core using standalone does not work because of duplicated types in Fake and this (closed) issue: https://github.com/dotnet/fsharp/issues/3473
• Using ilmerge approaches is not smart since https://github.com/gluck/il-repack seems abandoned and runs in net4.0 https://github.com/gluck/il-repack/blob/033e89aa521d5865dbdeb094cd521aaa03208359/ILRepack/ILRepack.csproj#L7

EDIT: previously i reportet, wrapping the function helps. I was suspicious about it and i can confirm, my test was wrong. i still get {"Method not found: 'Microsoft.FSharp.Collections.FSharpList`1<System.String> ReleaseNotes.get_Notes()'."}

[krauthaufen]

I think the upshot is quite simple: you will never be able to load two different fsharp.core versions directly, so i guess there's no way around AssemblyLoadContext/AppDomain which both don't exist in netstandard... Is the msbuild plugin running in a netframework environment?

[krauthaufen]

Afaik msbuild is running on netframework4.8 under VisualStudio, which would be terrible since there's no AssemblyLoadContext for isolating the thing. The only other way i can think of is some command-line thing which is also sort of terrible due to serialization/platform problems/etc.

[krauthaufen]

Maybe just copy the Release-Notes parser and be agnostic about FSharp.Core versions?

[haraldsteinlechner]

i just tried to peel of release notes parsing from fake. without success, digged deeper, no idea what the real cause of the missing method exn is. the whole idea of using packages within a build task is not robust. cmd line tool is the only option

[krauthaufen]

Its really simple: the return type for the method cannot be resolved since the requested FsharpList from 6.0 can indeed not be found

[haraldsteinlechner]

no it is not. at that time hunderts of lines of f# have worked. and it is not possible to load 2 different fsharp.core's. so something is strange. also i cannot reproduce it anymore

[haraldsteinlechner]

execution runs till here: Notes is not found, although the runtime type has a get_Notes.

[krauthaufen]

That is still how it is, most of fsharp.core is backwards compatible, so 90% of things just work, but the list used for compiling Fake.ReleaseNotes seems to be incompatible with the one from your Fsharp.core That doesn't necessarily mean different, its just some tokens/etc being different and that is precisely what happens.

Without our "accept every lib having the correct name" loading stuff your code would explode way earlier, so this is danger zone

[haraldsteinlechner]

so it is the FSharp.Core >= which causes the problem at some point.

[krauthaufen]

No I install custom assembly-loading stuff in the plugin afaik to simply ignore version mismatches which made the plugin work in older versions, but obviously this no longer helps. Basically there is no other option than an isolated environment for the whole thing

[haraldsteinlechner]

i did not know about this one ;) just found it in Utilities. So in the end we need to create a cmd line tool - and invoke it just like paket.

[krauthaufen]

Most likely yes, but that is a pain in the XXX since it needs to work on all platforms without opening terminal windows, etc.

[haraldsteinlechner]

i just linked fsharp.core statically, mono and sharpziplib are hopefully unproblematic, just trying to get a version out. What makes me wonder is that old aardvark.build versions had an empty dependency list - builds generated using pack.cmd have dependencies. i assume no dependencies is the right way

[krauthaufen]

Hey, since this is a build-only thing it shouldn't give you any transitive dependencies... So having no deps is actually quite important

[haraldsteinlechner]

i went the "let us just parse that little file ourselfs" path. when we have better solutions for isolated environments (or static link bugs fixed), we could switch to more robust FAKE again. I just wanted to make it work for all people being blocked by annoying failures.

PS.: i had sever problems publishing the package correctly. i switched to a getversion.fsproj and .cmd file to use paket pack which makes it work. dotnet pack seems to ignore the template file, aardpack currently still fails if no vs2019 is installed (see other issue)

[hyazinthh]

Parsing the release notes file ourselves also means that we can add support for comments. Would be useful for adding release notes without actually deploying a new package. Currently, you have to go over all commits and add them to the notes when you want to deploy a new version. This is cumbersome and may also lead to incomplete release notes if someone builds a package without doing that extra step.

@luithefirst suggested this at some point IIRC.

[haraldsteinlechner]

would be cool but this moves us away from standard release notes files. wouldn't it be simpler to just write a current_release_notes.md which tracks the changes, and finally when done it is copied into the real release_notes?

[krauthaufen]

The natural way would be prepending bullet-points without a version-heading? I think that should be fairly easy to ignore in the parser. Essentially this could be done by skipping everything before the first # at the beginning of a line.

[haraldsteinlechner]

the PR includes the final fix (without this feature request). please check if readme.md is appropriate in the PR https://github.com/aardvark-platform/aardvark.build/pull/6