Hi guys,
I’ve got a question real quick: does EBuild support the .NET Standard 1.6 as a target? I have a very simple project here that builds just fine for .NET Standard 2.0, but fails to build for .NET Standard 1.6 due to issues with resolution of classes from System.Threading namespace.
Thanks!
Ken
Ken,
It should yes; could it be that the types in question just aren’t in 1.6 yet? Can you send me a test case or let me know what exact types you are missing?
thanx!
Thanks for a quick reply Marc! That sounds good!
The types should be there as per MSDN - and I can also use them in a similar VS project. The common feature of the types affected is that they all are from System.Threading namespace (Monitor, AutoResetEvent, and ManualResetEvent). As per the EBuild trace, all the dependencies seem to be picked up by EBuild right, and seem to match those gathered by the VS project.
I’ve attached a sample project along with the build script. It builds fine with Release_NetStandard20 config, but doesn’t with Release_NetStandard16.
Thanks!
Ken
TestNetStd16Proj.zip (1.8 KB)
Ken,
hm, that is strange. If anything, I’d have expected a bug in EBuild resolving the wring package, but if you say it loads the same .dll that VC# does, that’s odd — must be something compiler side; I’ll log an issue for the compiler team to have a look.
thanx,
marc
Should be fixed for the next build!
Fantastic, thanks so much Marc!
any time!
Do you need an interim build, or is Friday good?
Friday is perfect, thanks!
Hi Marc,
I’ve just come across another issue when I tried to build a working .NET Standard 2.0 project on a different machine. While the symptoms are slightly different, it looks like it may have the same roots. The project - quite large - compiles well, but at the very end of the process I get the following message from EBuild:
E: Error while generating executable: Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: ‘netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’
Mono.Cecil.AssemblyDefinition Resolve(Mono.Cecil.AssemblyNameReference, Mono.Cecil.ReaderParameters)
Mono.Cecil.AssemblyDefinition Resolve(Mono.Cecil.AssemblyNameReference)
Mono.Cecil.AssemblyDefinition Resolve(Mono.Cecil.AssemblyNameReference)
Mono.Cecil.TypeDefinition Resolve(Mono.Cecil.TypeReference)
Void WriteCustomAttributeEnumValue(Mono.Cecil.TypeReference, System.Object)
Void WriteCustomAttributeValue(Mono.Cecil.TypeReference, System.Object)
Void WriteCustomAttributeElement(Mono.Cecil.TypeReference, Mono.Cecil.CustomAttributeArgument)
Void WriteCustomAttributeFixedArgument(Mono.Cecil.TypeReference, Mono.Cecil.CustomAttributeArgument)
Void WriteCustomAttributeConstructorArguments(Mono.Cecil.CustomAttribute)
Mono.Cecil.SignatureWriter GetCustomAttributeSignature(Mono.Cecil.CustomAttribute)
Void AddCustomAttributes(Mono.Cecil.ICustomAttributeProvider)
Void AddType(Mono.Cecil.TypeDefinition)
Void AddTypes()
Void BuildTypes()
Void BuildModule()
Void BuildMetadata()
Void Write(Mono.Cecil.ModuleDefinition, Mono.Disposable1[System.IO.Stream], Mono.Cecil.WriterParameters) Void WriteModule(Mono.Cecil.ModuleDefinition, Mono.Disposable1[System.IO.Stream], Mono.Cecil.WriterParameters)
Void Write(System.String, Mono.Cecil.WriterParameters)
Void WriteOutput(System.IO.Stream)Project ‘SecureBlackbox.Neo.Standalone_Ebuild’ failed to build.
On the ‘working’ machine the whole build output, line-by-line, is exactly the same, but instead of the above error message, a ‘Solution ‘SecureBlackbox.Neo.Standalone_Ebuild’ built successfully.’ line is output and the whole process succeeds.
I checked the reference resolutions reported in the log - including that for netstandard.dll - and they all look good and point to the right files. I just thought that it would be worth checking with you, before I embark on a deeper research, if you think this may have something to do with the fixed .NET Standard 1.6 problem above?
Thanks!
Ken
This is quite a different issue yes.
It should use the original assemblies as input for the rare cases where Cecil needs the input like this, and does (just checked the code).
Any chance of a testcase?
I’ll try to carve a standalone test case now - but please be prepared that it’s going to be quite large :). I tried reproducing it on a much smaller project, but then it didn’t expose itself.
Thanks guys!
Also, off hand, any idea about envious differences between the two systems where this fails vs. works? Different .NET SDK versions? Mac vs. Windows? Different Elements versions?
Good point. The working one is Windows 8.1, the non-working is Windows 7 SP1. Elements are of the same version (Version 10.0.0.2435 (develop) built on bajor, 20190830-144036). .NET SDKs, and, generally, the whole environments are the same too (but as .NET Standard references are resolved via NuGet, I guess that should be irrelevant?).
I can tell you it is an attribute with enum value where the enum is defined in netstandard
For what gets compiled, yes. But the compiler itself still runs on the .NET Framework version that’s installed, so if the compiler behaves differently with matching inputs, my first guess is a different in the environment it runs on.
(for example, the other day I had an issue where age-old code suddenly failed with a really odd error. What happened was that one f the letters in an identifier looked like a “C” to the naked eye, but was the unicode version of some some different Cyrillic letter that looks the same (copy/pastyed code snipped from StackOverflow, I guess). Which the compiler of course handles fine, as long as every place you use the identifier, you use the same character. But, turns out the version of Mono I was running the compiler on had issues with unicode, so the compiler didn’t see the C as a valid letter only on that one system).
That makes total sense. I checked the frameworks: indeed, on Windows 8.1 the version installed is 4.7, whereas on Windows 7 it’s still 4.0.
My old days - we used to play similar tricks with Cyrillic letters on each other at the uni (compilers weren’t that good with any characters but Latin at the time, so it produced all kinds of bizarre compilation issues straightaway). This trick is of the same scale as “define TRUE FALSE” in C; pretty non-obvious and takes enormous amount of time to locate. Hope the StackOverflow chap was eventually identified and brought to justice :).
Curious. Could you try if updating to 4.7 (or whatever newest still works on Windows 7) fixes it?
Ah yeah, that’s. nasty one 
Naa, i don’t even recall where the code came from; its some ancient wrapper function the deals with the macOS KeyChain, that I had not touched in years…