Compilation errors #24
Comments
|
@mterwoord That is odd. The Can you share out the compiler command line that is being used? That should be logged during build. EDIT I forgot on Windows the |
|
I have .NET 5 preview 6 installed on windows. Compiler output compiling |
|
@mterwoord Ah. This looks like #19. I just validated the nightly and the static lib is there. |
|
I just noticed that this is for x86. I just tried that and there is indeed a build issue for that. My confirmation above was only for x86_64 - the default for .NET Core. I will submit a PR with a fix today and publish a new package. |
|
The new package doesn't fix this error. I still get it. I'm on .net 5 preview 6.
If you want, we could schedule a remote session, so we can have a look around? |
|
@mterwoord The missing I don't think there is much that can be done for .NET 5 Preview 6 for x86. I can try installing it and see what is occurring if that specific preview is important, otherwise I would move up to the nightly. |
|
I just confirmed that Preview 7 and Preview 8 from here work. It seems that the Preview 6 is completely busted at this point. I could support the dynamic version of Really sorry about this confusion. I will update the |
|
Sorry for the late reply. Thanks for clearing things up. It works now, using Preview 7 from the link. Is it currently possible, or will it in the future, to use self-contained deployments? |
Yay!
A very important scenario. It isn't currently supported. Some of this idea is captured at dotnet/runtime#3750 (comment). That issue is still opened and supporting the self-contained scenario there would enable DNNE to support it as well. Feel free to file a more specific issue at https://github.com/dotnet/runtime/issues - a specific user request always carries more weight. /cc @vitek-karas @jkotas |
|
Not sure exactly about that comment. I read it 3 times now and still don't understand things.... It mixes self-contained deployment and single-file deployment, as far as I can see. I don't care (too much) about single file deployments. My current .NET 4.7-based setup deploys about 500 files for the .NET based stuff. |
|
@mterwoord Oh shoot. Sorry about that. The self-contained deployment for libraries is a bit more complicated here. @vitek-karas is still the right person here, but it is much less clear on how to support that properly. The primary concern is about the lack of support of side-by-side in coreclr - we can only load a single coreclr runtime in a process. This means that if the current component specifies a runtime and another component - let's say a COM server - is loaded, then which runtime wins? It is possible they can both use the same version, but what about if one specifies 3.1 and the other 5.0? This gets even more complicated depending on order of load because if 5.0 is loaded first it could work, but if 3.1 is loaded first it most likely won't. We have been starting to consider these scenarios because some know the exhaustive list of libraries they need and don't support plug-ins - see dotnet/sdk#12043. Being up front, I will say it isn't a simple ask. The complexity of how users would need to think about a single coreclr instance to satisfy all needs is very hard to get right and adding support and defining boundaries in a way that will ensure success is something we have been struggling with. Feedback and suggestions are always appreciated in this domain. |
|
Maybe I can fake self-contained deployment by manually including the runtime files and fooling around with environment variables a bit. I'll need to figure that out then. |
|
@AaronRobinsonMSFT I seem to have the same issue as the initial comment regarding DNNE.BuildTasks.dll here. For some reason, Visual Studio doesn't want to successfully build the ExportingAssembly example project (nor any other project that references DNNE from NuGet), while The error it spits out is as follows: Funny how the error message is partly Dutch 🤔. Since you asked the compiler command earlier, this is the one from Visual Studio:
This is the command from dotnet build:
This basically tells me that it's referencing 5.0.0-preview.7.20326.1, which I do not have installed. I've tried both preview7-20365.7 and preview8-20363.2 which are the latest at the time of writing. Both build logs here are from preview8. Is there any way to get this to work properly in Visual Studio without having to wait for .NET 5 to come out of preview? |
That is a good question. I honestly don't know the answer to that. I have used VS but recently been building from the command line since it limits issues. I tried to make this work by targeting .NET Standard 2.1, which it seems to reference properly the failure is confusing to me. What version of Visual Studio is being used here? |
|
This is in 2019, both 16.6.3 and 16.7.0 preview 3.1. |
|
@Archomeda I figured out this issue. I believe I have it fixed in #27. I have also published an updated package. |
|
@AaronRobinsonMSFT sorry for the late reply, I haven't had the time to check yet. I'll let you know when I've been able to confirm. |
I created a .net 5 library in VS preview. I added the DNNE package (latest version. Next I added a method
public static int Add(int a, int b), and marked it with the UnmanagedCallersOnlyAttribute.When I compile in VS, I get an error saying the
DNNE.BuildTasks.dllfile couldn't be loaded.When I run
dotnet buildfrom the command line, I get an error from the c++ compiler, saying it can't findlibnethost.lib.What am I doing wrong?
Is there a (working) sample project somewhere?
The text was updated successfully, but these errors were encountered: