Skip to content

Common Problems

Harald Steinlechner edited this page Mar 18, 2018 · 17 revisions

Q: MSBuild prints strange error messages

When building, msbuild complains about import attribues as such: ...The value "" of the "Project" attribute in element <Import> is invalid.... The complete log could look like this:

  C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe  src/aardvark.docs.sln /t:Build /m  /nodeReuse:False  /v:m  /p:RestorePackages="False" /p:OutputPath="C:\Users\Harald\Desktop\aardvark.docs\bin\Release" /p:Configuration="Release" /p:VisualStudioVersion="15.0" /logger:Fake.MsBuildLogger+ErrorLogger,"C:\Users\Harald\Desktop\aardvark.docs\packages\build\FAKE\tools\FakeLib.dll"
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Users\Harald\Desktop\aardvark.docs\src\Utils\Utils.fsproj(56,3): error MSB4020: The value "" of the "Project" attrib
ute in element <Import> is invalid.
C:\Users\Harald\Desktop\aardvark.docs\src\AdaptiveWorld\AdaptiveWorld.fsproj(56,3): error MSB4020: The value "" of the
"Project" attribute in element <Import> is invalid.

A: Maybe you have no F# tools installed.

A starting point for analysis is the F# import clause which can be found in .fsproj files. It typically looks like this:

  <Choose>
    <When Condition="'$(VisualStudioVersion)' == '11.0'">
      <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')">
        <FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </When>
    <Otherwise>
      <PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets')">
        <FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
      </PropertyGroup>
    </Otherwise>
  </Choose>
  <Import Project="$(FSharpTargetsPath)" />

As you can see, if no condition holds, the variable $(FSharpTargetsPath) remains empty, which leads to those empty-string-like erros during build.

The obvious solution is to install F# tools. Currently we use F# 4.0 which is shipped alongside VisualStudio 2015. Note that starting with VisualStudio 2017, F# tools are not installed by default anymore. This brings along a simple implication: by installing VisualStudio 2017, you can destroy your working VisualStudio 2015 F# setup...

Q: Build fails in Aardvark.Compiler.DomainTypes...

  1) Building src/Aardvark.Media.sln failed with exitcode 1.
  2) MSB4062: ...aardvark.media\packages\Aardvark.Compiler.DomainTypes.MSBuild\build\Aardvark.Compiler.DomainTypes.MSBuild.targets(7,5): The "Aardvark.Compiler.DomainTypes.Preprocess" task could not be loaded from the assembly Z:\repos\aardvark.media\packages\Aardvark.Compiler.DomainTypes.MSBuild\build\Aardvark.Compiler.DomainTypes.MSBuild.dll. Could not load file or assembly 'FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

A: Most likely you have no F# tools installed. @mikemay: this is your problem should be fixed by now?

Q: Startup problems: cannot find glvm.dll or vkvm.dll

A: make sure the dlls are beside your application. UnpackNativeDependencies in Aardvark.Init puts them there if possible. make sure you called aardvark.init if you don't package them with your deploy. (seealso https://github.com/aardvark-platform/aardvark.docs/wiki/Runtime-System)

Q: Oh nooooes, cef problems

A:

at some point we copied the correct cef version besides your application. this one is still preferred by assembly resolution which might lead to such exceptions as we switched to newer cef versions. (see debugging dll problems)

Q: DLL hell?

A: Managed

If you end up with missingmethodexcpetions, check the expected and actual ABI using ILSpy

A: Unmanged

Check what native dll is loaded by using visual studio output window or assembly bind logging (fuslogvwr)

Q: Nothing works. I always get messages crazy exceptions such as BadImageFormat....

A: You are most likely running the application in 32bit mode.

Most Aardvark components currently only work on 64bit...

Please check our stdout or the Aardvark.log file which is automatically created besides your application. Typically it looks like this:

 0:   System Information:
 0:     OSVersion: Microsoft Windows NT 6.2.9200.0
 0:     SystemArchitecture: 64-bit
 0:     Environment.Version: 4.0.30319.42000
 0:   Unpacking native dependencies .................................. 0.007 s
 0:   Loading plugins ................................................ 0.011 s
 0:   initializing PixImage .......................................... 0.070 s
 0:   initializing ModModule .................................................
 0:     initializing mod system ...................................... 0.001 s
 0:   initializing ModModule ......................................... 0.002 s
 0:   initializing NewAg ............................................. 0.005 s
 0:   initializing Ag ................................................ 0.000 s
 0:   initializing SceneGraphCompletenessCheck ....................... 0.060 s
 0: initializing aardvark ............................................ 0.179 s
 0: initializing OpenGL runtime ..............................................
 0:   vendor:   "NVIDIA Corporation"
 0:   renderer: "GeForce GTX 1080 Ti/PCIe/SSE2"
 0:   version:  OpenGL 4.3.0 / GLSL 4.3
 0: initializing OpenGL runtime ...................................... 0.149 s

As you can see, the system architecture here is 64-bit. Depending on what components you are using, 32bit leads to different errors: alt text Here for example you used the OpenGL backend combined with our native optimized code generator, which only works in 64bit. Note that depending on your backend configuration, 32bit might work --- it really depends on the used features. In Vulkan for example you would currently get: Unhandled Exception: System.Exception: [Vulkan] could not create instance.

Q: Why is my application in 32bit anyways?

A: In VisualStudio, new F# Projects accidentally run in 32bit due to visual studio oddness.

Check your configuration in Project Properties/Build:

alt text

Important: in order to fix this problem you need to

  • manually edit the project file, i.e. set the property manually to false false
  • delete the output directory, since during the first and most likely unsuccessful start, 32bit dlls might have been copied beside your application (TODO explain this in a separate article)

Q: Most features need 64bit, so why does not aardvark check for the bitness and stop if 32bit is detected?

A: It depends on the features you are using. AMD64 is the primary architecture, others could work for parts of the engine....

Q: Nothing works, I can not even build projects using aardvark.media.

A: VisualStudio 2015 + F# Power Tools + Aardvark.Compiler.DomainTypes is incompatible.

F# power tools use similar tooling as Aardvark.Compiler.DomainTypes which is used as MSBuild plugin for automatically generating incremental datatypes. Whenever F# power tools loads the wrong version of FSharp.CompilerServies, our msbuild plugin fails with errors like: Preprecessing failed... missing method excpetion ....

Q: My project works on my pc but not on my colleague's setup.

A: Make sure you did not confuse build install with build restore.

Q: What does shader functions may not access their vertex-input statically mean?

A: The expression, which creates an FShade shader fails.

This happens if shader inputs are accessed in the shader expression outside of a shader builder (e.g. vertex). If this is not the case, enable first chance exceptions in your debugger in order to find the real reason.

alt text

Since there is no obvious problem with our shaders (we are using standard shaders here), let us investigate the problem using thrown first chance exceptions (Debug/Windows/Exceptions).

alt text

Note that, in order to get first chance exceptions in third party code you need to disable just my code in visual studio:

alt text

With this we end up with the real reason (see next question).

Q: Nothing works, something with hmap fails.

alt text

This is a nasty exception, similarly to the dreaded MissingMethodExcpetion. See the next question.

Q: Nothing works. Something with MissingMethod.

A: This error occurs if semantic versioning of libraries is messed up, and we are using an incompatible version of a library.

The solution here is (this really happens super rarely) to pin the problematic library to a specific version.

In the case of this hmap problem, mentioned a few questions earlier, the proper version constraint is: nuget Aardvark.Base = 3.0.45

Q: Nothing works. Something with bad image

A: make sure to disable prefer32bit in your project settings!

alt text

Q: I cannot push packages

A: Make sure to have a nuget key registered for the feed defined in deploy.targets.

The key needs to be in USERDIR/.ssh/

Q: I cannot push packages

A: Make sure you have set up SSH for git properly.

When using tortoise git make sure to tick OpenSSH while installation (for pushing packages you need proper ssh setup)

alt text

Q: Nothing works in media. something with cef. again


Unhandled Exception: Xilium.CefGlue.CefVersionMismatchException: CEF runtime version mismatch: loaded version API hash "7ece9a94eb706c0814b34b3bb4dc227edf46fdec", but supported "b881890cc9f9ab64382aee812d483a6873d8b1af" (3.3282.1741.gcd94615).

A: delete your output folder in order to get rid of wrong cef versions which are automatically preferred instead of our custom download.

Clone this wiki locally
You can’t perform that action at this time.