Netcoreapp3.1

[jackfoxy]

update HelloWorld, Gravity, BackgroundColor, and AdaptiveWorld to netcoreapp3.1

[haraldsteinlechner]

hi @jackfoxy

i'm not sure if it is a good idea to have multiple paket.dependencies in multiple folders for one solution? aardvark.docs was i think paket-free for easier access to dotnet community. isn't it better to have all vanilla netcore or all paket with one single paket.dependencies?

any thoughts? @luithefirst @krauthaufen

[jackfoxy]

Hi @haraldsteinlechner

I agree. I modeled the updates after the Sky and SSAO folders, which were already 3.1, so I thought that might be the new preference of the project maintainers.

Personally I also like miscellaneous files like .gitignore, yml's, readme's to be accessible in solution folders. What do you think?

I can make all or any of these updates to the PR. Let me know.

[haraldsteinlechner]

i kind of forgot that for example SSAO was using paket - for good reasons as i remember. however i think when opening the solution everything should work - with this setup at least i get stuff tons of errors unless paket restore is invoked for several folders. i think especially aardvark.docs should be approachable. i would opt for vanilla dotnet for everything. if hardly possible, paket.dependencies in root. what to others think? already mentioned people and @aszabo314 @hyazinthh

[krauthaufen]

Hey, I think the standard dotnet way of handling transitive depenencies is just not manageable... Maybe we should just use paket and put some build instructions im the readme? I think most people are used to these things anyway... The other option would be to specifiy a ton of dependencies in every project since afaik there is no dotnet-way of handling transitive depenencies in a reasonable way. (I'd be happy if someone proves me wrong)

[jackfoxy]

One paket dependencies file.

SierpinskiTetrahedron, ModelLoader still netcoreapp2.0

All projects build, with many warnings for SierpinskiTetrahedron.

SierpinskiTetrahedron and ModelLoader do not run.

In another branch ModelLoader can build in netcoreapp3.1, but fails on a different runtime error.

SierpinskiTetrahedron almost builds in netcoreapp3.1, but I do not know how to make the FSharp.Data.Adaptive update build this line in Program.fs

let t = Mod.map2 (fun (t0 : DateTime) (t : DateTime) -> (t - t0).TotalSeconds) t0 Mod.time

[krauthaufen]

Cool, I'll take a look at that tomorrow, we removed Mod.time for several reasons, but since it's most likely used for some animation here, We could replace it with IRenderControl.Time... When no rendercontrol is available, there are several other "hacks" I can think of...

[jackfoxy]

It looks like installing VS 16.6 installed sdk 3.1.300 and uninstalled 3.1.202. The builds for Sky.fsproj and SSAO.fsproj now hang with 3.1.300 and never finish. I will have to fix this.

[haraldsteinlechner]

actually i got distracted while appending your PR in order to merge. when you touch it - could you please move the paket stuff and the solution top level - this way people find it more easily?

the build problem comes from adaptify i suspect which was broken at some point. could you check if updgrading adaptify.msbuild to newest version fixes your problem?

[jackfoxy]

I was also finding it annoying the solution was not at top level. It is very probably adaptify. I'm getting warnings on adaptify, and adding a global.json pointing to 3.1.202 did not fix the problem. On my machine that has not been updated to VS 16.6 this still builds.

I updated to the latest Adaptify.MSBuild, 0.0.46 and still same situation. It hangs during the build on my updated machine, but not on the machine on the older version of Visual Studio. Although the warning messages about adaptify have gone away doing a dotnet build in powershell. I still get the warning "falling back to local adaptify" in VS.

Could this be significant? Adaptify warning 3005: Referenced assembly 'C:\Users\jackf\.nuget\packages\aardvark.base.typeproviders\4.5.15\lib\netstandard2.0\Aardvark.Base.TypeProviders.dll' has assembly level attribute 'Microsoft.FSharp.Core.CompilerServices.TypeProviderAssemblyAttribute' but no public type provider classes were found

[jackfoxy]

Solution and paket files moved to top level. Still does not build in Appveyor because .gitignore specifically excludes Paket.Restore.targets. Do you want to keep it this way?

[haraldsteinlechner]

people often used to commit a paket bootstrapper.exe and run this as prebuild step (.paket/paket.exe restore). we did this for most other aardvark repos. this could solve the ci troubles. i will look into your adaptify issue tomorrow. then let us merge! thank you very much. aardvark.docs is important :)

Jack Fox notifications@github.com schrieb am Mo., 25. Mai 2020, 23:04:

Solution and paket files moved to top level. Still does not build in Appveyor because .gitignore specifically excludes Paket.Restore.targets. Do you want to keep it this way?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aardvark-platform/aardvark.docs/pull/27#issuecomment-633715741, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5KAMTGQ5BR5M2UAAK3X3RTLMNBANCNFSM4NAEJMCA .

[haraldsteinlechner]

hi @jackfoxy,

the adaptify problem should be fixed here https://github.com/krauthaufen/Adaptify/commit/81e9ba3ff34b62c6d101f210b9719ec22f08919a and in the package https://www.nuget.org/packages/Adaptify.MSBuild/

could you check this one out?

[jackfoxy]

Updated to 0.0.48 Adaptify.MSBuild. Everything builds. All netcoreapp3.1 projects run.

SierpinskiTetrahedron netcoreapp2.0 projects runs.

ModelLoader netcoreapp2.0 projects fails at runtime.

Unhandled Exception: Assimp.AssimpException: Error loading unmanaged library from path: Assimp64.dll, see inner exception for details.
The specified module could not be found. (Exception from HRESULT: 0x8007007E) ---> System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   --- End of inner exception stack trace ---
   at Assimp.Unmanaged.AssimpLibraryWindowsImplementation.NativeLoadLibrary(String path) in D:\Development\assimp-net\src\AssimpNet\Unmanaged\AssimpLibrary.cs:line 1683
   at Assimp.Unmanaged.AssimpLibraryImplementation.LoadAssimpLibrary(String path) in D:\Development\assimp-net\src\AssimpNet\Unmanaged\AssimpLibrary.cs:line 1541
   at Assimp.Unmanaged.AssimpLibrary.LoadLibrary() in D:\Development\assimp-net\src\AssimpNet\Unmanaged\AssimpLibrary.cs:line 143
   at Assimp.Unmanaged.AssimpLibrary.CreatePropertyStore() in D:\Development\assimp-net\src\AssimpNet\Unmanaged\AssimpLibrary.cs:line 505
   at Assimp.AssimpContext.CreateConfigs() in D:\Development\assimp-net\src\AssimpNet\AssimpContext.cs:line 1006
   at Assimp.AssimpContext.ImportFile(String file, PostProcessSteps postProcessFlags) in D:\Development\assimp-net\src\AssimpNet\AssimpContext.cs:line 285
   at Aardvark.SceneGraph.IO.Loader.AssimpModule.loadFrom(String file, PostProcessSteps postProcessingFlags) in C:\Users\Schorsch\Development\aardvark.rendering\src\Aardvark.SceneGraph.IO\IO.fs:line 774
   at Program.main(String[] argv) in C:\Users\jackf\GitRepos\aardvark.docs\src\ModelLoader\Program.fs:line 24

[haraldsteinlechner]

i'm sorry for the late merge - i fixed the model loader problem in master. actually at the same time @luithefirst added an awesome sky demo. I'm not happy with the currently mixed paket and non-paket thing. maybe when moving everyting to v5 we can fix this one as well...