"error: syntax error at token '.' in .interfaceimpl type..."

[nitz]

Steps to reproduce:

• Download attached project and extract to folder.
• Restore packages, build.
• Observe error.

• DllExport -version: v1.7.4.29858+c1cc52f
• Used Visual Studio / MSBuild : MSVS 17.1.0 / MSBuild 15.9.21+g9802d43bc3

Information from Data tab or log data:

data tab: dllexport-data-tab.txt

msbuild with /v:diag: build.log

Project Sample

Project zip: DllExport-Error-LibSandbox.zip

This is the code from Example.cs, but the entire project has been attached, so you may see my DllExport settings, as well as the overall project settings.
N.B.: This error becomes evident when built with C# language version 8+, with nullable reference types enabled. Using a Language version 7.3 or lower (no NRT), or setting nullable reference types to any setting other than enabled will not produce the error.

using LibSandbox.Native;

namespace LibSandbox
{
	interface IFooProvider
	{
		object Inst { get; }
		void Bar(object o);
	}

	class FooProvider : IFooProvider
	{
		public object Inst => new object();
		public void Bar(object o) { }
	}

	public class Example
	{
		[DllExport]
		public static void Baz() { }
	}
}

Details

So this is a truly bizarre one that I've stumbled across today. I've narrowed it down to a very minimal reproducible example. It appears to be a combination of nullable reference types, and interface implementations.

With the project exactly as it is in the zip above, trying to rebuild will yield the error:

error : syntax error at token '.' in:   .interfaceimpl type 'LibSandbox'.'IFooProvider' [...]

However, it seems to be extremely dependant on a number of things. Below, I've listed some modifications. Any single one of the changes below will allow the project to build successfully. Undo the change, and the error returns.

• Remove IFooProvider.Inst (and subsequently FooProvider.Inst)
• Remove IFooProvider.Bar (and subsequently FooProvider.Bar)
• Change IFooProvider.Bar to take an int instead of object (and subsequently FooProvider.Bar)
• Remove the parameter from IFooProvider.Bar (and subsequently FooProvider.Bar)
• Add #nullable disable at the top of Example.cs
• Change <Nullable>enable</Nullable> in LibSandbox.csproj to <Nullable>warnings</Nullable>
• Remove [DllExport] from Example.Baz
• Remove the entire FooProvider class.

Perhaps some other things would work around this issue, too.

Naturally, (as I'm sure you could imagine), I'm unable to make any of the changes in my actual project, which is why I've turned to posting here.

Let me know if there's more information I can provide!

[3F]

Hello, Thanks for the detailed report! It's really appreciated!

You can try Use our IL Assembler option, seems it helps.

I'll look into later for details but it looks like a bug exactly in 3rd-party MS IL Assembler because the same instructions still are valid in my version.

Also note Rebase System Object option in case of some unexpected exceptions at runtime since you're targeting netstandard

[nitz]

Switching to Use our IL Assembler does seem to work with my example and in my larger project right now! Seems like a valid path for the time being! Fantastic, thank you!

Not sure if this is related to switching to this option or if the behavior was there the whole time and I just didn't realize before. (I can move this to a new topic if needed.) Now each time I build my solution, my project with DllExports in it re-builds (or well, at least re-outputting the DLL) every time. It's a project that's early on in my chain, so it's slowing things down considerably, as is taking 10-15 seconds each time. Have I done something wrong that's causing it to appear "out of date" to msbuild each time?

[nitz]

Hi Denis,

I've hit a bit of a roadblock with <DllExportOurILAsm>true</DllExportOurILAsm>: it seems using that IL assembler means I don't get debugging info (.pdbs)? Best I can tell from your post here is that might be intentional at this time? Is there something I'm missing that will make sure the pdb gets generated?

[3F]

Hi Chris,

the .line feature yet controlled by this issue 3F/coreclr#3

And I'm not really sure when I'll be ready to do something with it

Whenever I want to do something in my open projects ... always, something is always happening to destroy me and everything around me. What the . . .

I'm sorry today it's too hard to me again to say something about anything at all. Thank you for your interest to my projects! I'll try to review any actual issues later as possible for me.

Regarding to,

Not sure if this is related to switching to this option or if the behavior was there the whole time and I just didn't realize before. (I can move this to a new topic if needed.)

Yes, please open a new one. It could be either a bug or simply unwanted behavior which can be reviewed independently.

With best regards,
-- Denis

[nitz]

And I'm not really sure when I'll be ready to do something with it

I know this feeling entirely! 😅

And no worries, I appreciate all the effort you put in. For now, I've fallen back to targeting the .NET Framework 4.8 and that seems like it's going to be a viable workaround while I'm developing: I'm able to use the default IL Asm (thus getting the PDBs), and don't get stuck with the issue opened with this ticket. It's not my long-term solution as I do hope I'll be able to target .NET proper (via .NET Standard) in the future, but this gets me 90% of the way there!

Yes, please open a new one. It could be either a bug or simply unwanted behavior which can be reviewed independently.

Will do, when I can craft a standalone example that recreates it. It doesn't happen with all of the changes I mention above switching framework, IL asm, etc, so I'd like to narrow it down before submitting something on it.

Thanks again for taking a look!