strange behaviour of the compiler / runtime system !?

[Phil Hepburn]

Hi Team guys - Robert and Chris,

This morning I came across a strange situation with some new X# code I was creating and testing.

I have a STATIC method which works ok (and gives the correct results) if, and only if, I have one (or two) MessageBox.Show() statements working.

When I comment one or both, then I get an error at runtime.

I will start by posting here a couple of images. Then tell me what else I need to do to help you out.

StrangeXS_01.jpg (117.73 KiB) Viewed 879 times

StrangeXS_02.jpg (102.11 KiB) Viewed 879 times

StrangeXS_03.jpg (79.03 KiB) Viewed 879 times

The project is very small - in case you need it to look at.

Best regards,
Phil.

[robert]

Phil,

- What is the path of the file that gives the 'BadImageFormat' exception
- Does this file exist ?
- Does it depend on other assemblies, and do they exist ?
- What does the code look like that "finds all the DLLs" ?

Robert

[Phil Hepburn]

Hi Robert,

Probably the best thing is for me to provide the project file and folders (its quite small).

Here is the OneDrive link.

https://1drv.ms/f/s!AiCBl-gBWjY9hep3iEYqGsKwxVZPQA

To sort of answer your questions - all the other parts have been tested out and work correctly.

So the files exist as does the code to FindAll ....

And with the two lines commented out the error happens, but with them uncommented the code works correctly.

In fact here is a printout to show it working with just one Message commented :-
[ .. feels very weird to me .. ]

StrangeXS_11.jpg (111.48 KiB) Viewed 879 times

Just in case, I will now start my VS and maybe o/s again just to be sure. I sit here for many hours each day and stuff just works for me (after a bit of effort), but this feels weird to me.

Fingers crossed and good luck.

Phil.

[TerryB1]

Phi

FWIW and please bear in mind my experience is with C# not XSharp:

It may be worth trying Assembly.ReflectionOnlyLoadFrom(.....)

rather than Assembly.LoadFile(....)

as long as you don't need to instantiate types (loading an assembly into the current application can cause problems with statics).

Terry

[Phil Hepburn]

Hi Terry,

Thanks for the idea and advice. Looks like a good tip.

I have just tried it and got the same result. It obviously works - BUT !

Note however that I did not have the call to STATIC code within the parameter list - it was the simple string variable.

My feeling is that when I come to use the string variable 'cPath' it does not (for some reason or another) contain the string it should at the time it is being used. I have not used any code anywhere which is Async and/or Await etc. Just simple coding.

I will now wait to see what the Team comes up with.

Best regards,
Phil.

[robert]

Phil,
It crashes here too.
I made a small change to your program so I can access the cPath variable in the catch clause and this shows me that the file that fails is:
"C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.2System.EnterpriseServices.Thunk.dll"
When you inspect this file with Reflector or ILSPy you can see that this is not a .Net assembly.

And terry is right, you should try to use ReflectionOnlyLoad. The way you are doing it now the DLLs and their types will be loaded in the memory space of the running app. That could cause problems!

Robert

[Phil Hepburn]

Thanks Robert, (and Terry as well)

I will change the code back to Terry's way.

I actually have it working here but not by being as clever as you ;-0)

It seems that there may be up to three files not of the correct format, and 129 which are - all in what I thought was a protected MS folder for Framework dlls.

I will now see if I can find out these three ? file names.

Thanks once again for you help - both of you.

The code I posted, although needing a lot of tidying and polishing does provide an interesting little app for Cologne and examples of using Collections and LINQ and a few othe modern bits too.

Cheers,
Phil.

[Phil Hepburn]

Hi again Robert and all,

In fact it was just two wrong format files.

As well as "Thunk.dll" in 'System.EnterpriseServices' there is also "Wrapper.dll" also belonging to 'System.EnterpriseServices'.

The other 129 seem okay ;-0)

StrangeXS_21.jpg (47.97 KiB) Viewed 880 times

Any thoughts why these are present in the folder, or where they have come from ?

Cheers for now - LOADS of snow in Newport, South Wales.
Happy March to all - this should be the first day of spring !

Phil.
Wales, UK.

[Chris]

I am getting an error here also with the file "presentationframework.aero2.dll". Phil, the dlls located in the "Reference Assemblies" folder are not "real" dlls, they do not contain code but only type information for reference and they are designed to be loaded only with Assembly.ReflectionOnlyLoadFrom() as Terry and Robert said.

If you attempt to load one of those dll files with "normal" (executable) reflection, then the system actually loads the equivalent dll from the GAC, instead of from the "Reference Assemblies" folder. You can see that by printing the "Location" property of the Assembly object, after you obtain it.

Problem in my machine is that presentationframework.aero2.dll does not exist in my GAC, so I am getting an error on it. Using Assembly.ReflectionOnlyLoadFrom() instead, works correctly on it. Of course nothing will work with "System.EnterpriseServices.Thunk.dll", as Robert pointed out this is not a .Net dll.

Chris

[robert]

To follow up on this: this is one of the differences between Vulcan and X#.
The Vulcan compiler will load an assembly from the GAC and not the references assemblies folder.
As a result it is possible that even if you specify that you compile against Framework 4.0 you can still call methods from Framework 4.5.

The way this works is:
Each reference assemblies subfolder has assemblies with only the methods and properties supported by that version of the framework. So if a method was added in 4.6, then the 4.0 and 4.5 folders will have assemblies that do not list this method. The 4.6 folder will list that method. If 4.6 is the active version of the framework on your machine, then the GAC will hold a 4.6 assembly. There is indeed no code in these reference assemblies, only a list of types, methods and properties. Like a dictionary.
I am not sure how the DLLs in the reference folder are created. There is no "special" compiler flag that creates just the metadata.
I think there is an (internal) Microsoft tool that takes a "normal" assembly and strips out the internal and private types, fields, methods etc as well as the code from all the method bodies.
If you inspect the reference assemblies closer you will also see that they have a referenceassembly attribute: [assembly: ReferenceAssembly]
This helps to identify a reference assembly as such.


Robert