cannot open source file

[tg2k]

After deleting my bin/obj folders, I get this when trying to build:

c1 : fatal error C1083: Cannot open source file: '<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\BC3.g.c': No such file or directory

I've seen this with multiple projects (I've created new projects multiple times when encountering this problem).

This is an x86 project and does have

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

set per #58 and this commit .

[AaronRobinsonMSFT]

Hi @tg2k Are you using Visual Studio to build? If so, can you try doing a rebuild? If not, in Visual Studio can you provide the commands you are running, including when and where deleting of bin/obj.

Out of curiosity, why are the bin/obj directories being manually deleted?

[tg2k]

Yes, I'm using Visual Studio 2022 Community, and I installed the latest x64 and x86 .NET 6 SDKs this morning.

I manually deleted bin/obj to create a clean slate build while debugging other issues.

Here's the build log for a Rebuild All as it hits this project:

Rebuild started... 2>------ Rebuild All started: Project: BC3, Configuration: Debug Any CPU ------ 2>Generator: 'obj\Debug\net6.0-windows\win-x86\BC3.dll': 2>Method 'TestGetStr' has non-exportable type 'String' 2>Building native export: "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\Hostx64\x86\cl.exe" /Od /LDd /TC /MT /GS /Zi /D DNNE_ASSEMBLY_NAME=BC3 /D DNNE_COMPILE_AS_SOURCE /I "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\include" /I "C:\Users\<userid>\.nuget\packages\dnne\1.0.32\tools\platform" /I "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86\6.0.10\runtimes\win-x86\native" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\shared" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt" "<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\BC3.g.c" "C:\Users\<userid>\.nuget\packages\dnne\1.0.32\tools\platform\platform.c" /link /DLL /LTCG /LIBPATH:"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\lib\x86" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x86" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x86" "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86\6.0.10\runtimes\win-x86\native\libnethost.lib" Advapi32.lib /IGNORE:4099 /IMPLIB:"<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\bin\BC3NE.lib" /OUT:"<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\bin\BC3NE.dll" 2>Microsoft (R) C/C++ Optimizing Compiler Version 19.31.31104 for x86 2>Copyright (C) Microsoft Corporation. All rights reserved. 2> 2>BC3.g.c 2>c1 : fatal error C1083: Cannot open source file: '<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\BC3.g.c': No such file or directory 2>platform.c 2>Generating Code... 2>C:\Users\<userid>\.nuget\packages\dnne\1.0.32\build\DNNE.targets(154,5): error MSB3073: The command ""C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\Hostx64\x86\cl.exe" /Od /LDd /TC /MT /GS /Zi /D DNNE_ASSEMBLY_NAME=BC3 /D DNNE_COMPILE_AS_SOURCE /I "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\include" /I "C:\Users\<userid>\.nuget\packages\dnne\1.0.32\tools\platform" /I "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86\6.0.10\runtimes\win-x86\native" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\shared" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt" "<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\BC3.g.c" "C:\Users\<userid>\.nuget\packages\dnne\1.0.32\tools\platform\platform.c" /link /DLL /LTCG /LIBPATH:"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\lib\x86" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x86" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x86" "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86\6.0.10\runtimes\win-x86\native\libnethost.lib" Advapi32.lib /IGNORE:4099 /IMPLIB:"<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\bin\BC3NE.lib" /OUT:"<path>\BC3\obj\Debug\net6.0-windows\win-x86\dnne\bin\BC3NE.dll" " exited with code 2. 2>Done building project "BC3.csproj" -- FAILED.

It may be worth adding that I was just creating a number of test methods to verify basic behavior, and in so doing I noted that at present there doesn't seem to be a way to return a string or directly accept an object passed in as a COM reference. I'm assuming I can work around the reference object issue using something like IntPtr but not sure about the string return.

[AaronRobinsonMSFT]

'\BC3\obj\Debug\net6.0-windows\win-x86\dnne\BC3.g.c'

Does any part of this path exist? I'm very confused as to why this would since if the bin/obj directories are deleted, then the entire build process would start again.

and in so doing I noted that at present there doesn't seem to be a way to return a string or directly accept an object passed in as a COM reference. I'm assuming I can work around the reference object issue using something like IntPtr but not sure about the string return.

The DNNE project is about a low-level near zero-overhead approach to exposing types to native code. The .NET string is a managed type and has no definition outside of the .NET environment. If you would like to return this, the recommendation is to use either byte* for UTF-8 encoding or char* for UTF-16 encoding. These two can be created using functions found on the Marshal class, see StringToCoTaskMemUTF8() or StringToCoTaskMemUni(). Please read the documentation for these methods since the memory management semantics are important to consider.

[tg2k]

BC3\obj\Debug\net6.0-windows\win-x86\dnne exists, but the BC3.g.c file isn't there.

Thanks for the advice on marshalling, I'll definitely make use of it if I'm able to return to investigating this approach to interop.

[AaronRobinsonMSFT]

@tg2k Let me confirm one more thing. In your project, I am assuming there is at least a single exported function marked with UnmanagedCallersOnly, correct?

[tg2k]

@AaronRobinsonMSFT Yes, I did have one, but your reply prompted me to experiment around that. The following code will Rebuild All fine, regardless of whether there is bin/obj already:

        [UnmanagedCallersOnly]
        public static void UCO() { }

But this code (which you established above is not correct code) will only successfully Rebuild All after there has first been a successful build without it:

        [UnmanagedCallersOnly]
        public static void UCO() { }

        [DNNE.Export(EntryPoint = "TestGetStr")]
        public static string TestGetStr()
        {
            return "test";
        }

When I replace this with marshalled code however it does build:

        [UnmanagedCallersOnly]
        public static void UCO() { }

        [DNNE.Export(EntryPoint = "TestGetStr")]
        public static IntPtr TestGetStr()
        {
            return Marshal.StringToCoTaskMemUni("test");
        }

It may be worth handling the build more gracefully when there is an illegal signature present.

Aside from that, it would be great if there was a more detailed explanation around how to customize entry point names to get around decoration while still controlling calling convention. What's in the readme doesn't convey what I actually need to add or edit in the C# project. It mentions DNNE.props which is inside the NuGet package folder rather than anything inside the project, and I don't see a way to actually provide a .def file in a C# project.

[AaronRobinsonMSFT]

It may be worth handling the build more gracefully when there is an illegal signature present.

Hmm. Let me see how that would work.

What's in the readme doesn't convey what I actually need to add or edit in the C# project. It mentions DNNE.props which is inside the NuGet package folder rather than anything inside the project, and I don't see a way to actually provide a .def file in a C# project.

Those are MSBuild properties that you can set inside your project. They are defined in that props file for documentation purposes and describe what they do. It should be as simple as setting the property to a defined .def file. The same applies to all those MSBuild properties, define them in your project with the desired values.

<DnneWindowsExportsDef>MyExports.def</DnneWindowsExportsDef>

An example of what the MyExports.def file could look like. Raymond Chen has a more accessible discussion of this topic.

EXPORTS
    MyExports=_MyExports

[tg2k]

Thanks for the clarification. I've worked a little with .def files but the instructions left me wondering whether I needed a copy of DNNE.props or whatnot. Adding in the DnneWindowsExportsDef directive and a .def file does indeed work. One minor note is that the .def file doesn't require the LIBRARY directive, but if you include one, it needs to include the NE suffix or it will trigger a warning.

[AArnott]

vs-threading has a similar problem. The build is fine, but VS itself reports two errors in the error list:

Transcribed as text below for searchability:

Severity	Code	Description	Project	File	Line	Suppression State	Tool
Error	MSB3073	The command ""C:\Program Files\Microsoft Visual Studio\2022\Main\VC\Tools\MSVC\14.35.32124\bin\Hostx64\x64\cl.exe" /Od /LDd /TC /MT /GS /Zi /D DNNE_ASSEMBLY_NAME=SosThreadingToolsManaged /D DNNE_COMPILE_AS_SOURCE /I "C:\Program Files\Microsoft Visual Studio\2022\Main\VC\Tools\MSVC\14.35.32124\include" /I "C:\_nugetpackages\dnne\1.0.32\tools\platform" /I "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\7.0.1\runtimes\win-x64\native" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\um" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\ucrt"  "C:\Users\andarno\source\repos\vs-threading\obj\src\SosThreadingTools\Debug\net7.0-windows\dnne\SosThreadingToolsManaged.g.c" "C:\_nugetpackages\dnne\1.0.32\tools\platform\platform.c" /link /DLL /LTCG /LIBPATH:"C:\Program Files\Microsoft Visual Studio\2022\Main\VC\Tools\MSVC\14.35.32124\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\um\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\ucrt\x64" "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\7.0.1\runtimes\win-x64\native\libnethost.lib" Advapi32.lib /IGNORE:4099 /IMPLIB:"C:\Users\andarno\source\repos\vs-threading\obj\src\SosThreadingTools\Debug\net7.0-windows\dnne\bin\SosThreadingTools.lib" /OUT:"C:\Users\andarno\source\repos\vs-threading\obj\src\SosThreadingTools\Debug\net7.0-windows\dnne\bin\SosThreadingTools.dll" " exited with code 2.	SosThreadingTools	C:\_nugetpackages\dnne\1.0.32\build\DNNE.targets	154		Exec
Error	C1083	Cannot open source file: 'C:\Users\andarno\source\repos\vs-threading\obj\src\SosThreadingTools\Debug\net7.0-windows\dnne\SosThreadingToolsManaged.g.c': No such file or directory	SosThreadingTools	C:\Users\andarno\source\repos\vs-threading\src\SosThreadingTools\c1	1		Exec

[AaronRobinsonMSFT]

@AArnott Is this consistent? Should I be able to reproduce this locally?

[AArnott]

Yes. These steps should repro it:

git clone https://github.com/microsoft/vs-threading/
cd vs-threading
.\init.ps1 # or init.cmd if you're using cmd.exe. This ensures you have the required .NET SDK installed.
.\Microsoft.VisualStudio.Threading.sln

My guess is once you build once, a fresh open in VS won't show this error. If so, you should be able to reproduce the problem as I did by running git clean -fdx :/ in the repo while VS is closed.

[AArnott]

Another thing that concerns me about this message is that it means VS is trying to run cl.exe in its design-time build, which is totally inappropriate, as it will slow down a great many other design-time experiences in VS. In fact this failure appears to be breaking the design-time build, which is now producing many more errors in the error list as the language service cannot fully initialize.

[AaronRobinsonMSFT]

Another thing that concerns me about this message is that it means VS is trying to run cl.exe in its design-time build, which is totally inappropriate

@AArnott That is entirely possible and likely the case. I wrote most of this while testing outside of VS. I assume following these docs will help avoid a majority of these problems, https://github.com/dotnet/project-system/blob/main/docs/design-time-builds.md.