IL2CPP/ Burst/ Linker Problem with dll

Scripting Burst
, , ,
1

I am working on a project where we need to integrate a CAN communication.
The customer is using a device from Peak. It has a NuGet .Net Standard 2.0 package [Peak.PCANBasic.NET]
Platform: Windows

The problem is that we can’t build with IL2CPP and Burst. Just Mono works. However, this is very constraining for us.
As soon as IL2CPP/Burst is included, we can no longer build. As it strips too much away?

>> The following error appears in the editor:

>> On a build, it ends with the following error:

I already tried adding dll’s and much more to the root and/or assets path. But this did not change anything.
Trying with link.xml didn’t work either.

Right now, the best solution would be to separate this into a dedicated application and communicate via sockets, but this would increase the overhead and error-proneness.

Would anyone think of a way to solve this without a mono build. Are there burst settings that I am not aware of?

Would appreciate any help.
Thanks.

2

These errors generally mean that something is wrong with that DLL. Do you have source code to it? You could try recompiling it against .NET Standard 2.1 if you do.

Otherwise, you could also try running PEVerify tool on it to see if it finds any issues.

3

Thanks for your answer.

Source Code
Sadly, I don’t have the source code for it.
When I decompile the .dll (just to find a clue) with dotPeek I can see that the code is obfuscated.
Additionally, in the methods, it writes only: // ISSUE: unable to decompile the method.

PEVerify tool
Unfortunately, I do not know really how to use it. But I have run two options.

- Option /md

- Option /il

I don’t know if I used the tool correctly.

I am open to advice.

Thanks

4

The /md option shows that the DLL contains invalid metadata. Unfortunately since both IL2CPP and Burst need to read this metadata, they have to assume the DLLs are valid and if they’re not things go wrong (like in this case).

Since you don’t have the the source code, I would try contacting the authors of this DLL and asking them to fix the metadata entries. It’s likely their obfuscator that is messing it up.

Unfortunately I don’t think you have any other options, if you need to use this DLL :confused: