Back to Questions
3.0k
views9
comments
2009 CTP and XNA compatibility problem
f#

I've been working on a program for the Zune using F#, and aside from not being able to use the PowerPack, it has been going smoothly using the 2008 CTP.

After upgrading to the 2009 CTP, however, I get the following warning:

Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly '..\..\zenReaderLib\zenReaderLib\bin\Release\zenReaderLib.dll' or one of its dependencies.

This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

And the program does not build. I'm using the VS2008 Shell for the F# .dll and referencing it in an XNA project on VC#2008 Express, so how could the F# project be built by a newer runtime?

.

I also tried changing the FSharp.Core references to the new version designed for the compact framework (BTW: the VS Shell wont let me add references to the v3.5 Compact Framework F# libraries for some reason, had to link to the v2.0 CF FSharp.Core instead), I also tried removing and re-adding my project reference, but I just get this warning:

The referenced component 'zenReaderLib' could not be found.

Followed by the warning in my previous post when I try to build the project.

If no one has any suggestions, I guess I'll have to go back to the 2008 CTP in order to finish my program.

By on 6/13/2009 11:08 AM ()

I have now hit the same issue.

Unlike FunctionalCanadian, I'm working with the Xbox 360, not the Zune.

Everything was fine until I tried to use Thread.SetProcessorAffinity, which is available only on the Xbox' version of mscorlib.

The F# compiler reported that no such method existed. The reason was that I had apparently been implicitly linking against the PC's version of mscorlib, which does not seem to have this method.

After adding an explicit reference to mscorlib from XNA/v3.0/References/Xbox360, I could compile my F# code, but could no longer link it with the top-level C# code. The error was the same as FunctionalCanadian got.

By the way, if I comment out the call to SetProcessorAffinity and remove the reference to mscorlib, the game runs fine (though a bit slowly) on the Xbox.

I'm still using XNA 3.0, I haven't tried using XNA 3.1 yet.

By on 8/3/2009 3:46 PM ()

In general, all your F# code must reference the same FSharp.Core.dll, and FSharp.Core.dll must be in sync with mscorlib.dll. So ensure that the right versions of both those assemblies are being referenced.

See also this thread

[link:cs.hubfs.net]

which discusses some VS bugs. It's possible that bugs in the assembly reference logic in VS are preventing the right stuff in the .fsproj file (and thus MSBuild). Check carefully the MSBuild output (in the VS output window, the long line that invokes fsc.exe when you build - 'modify tools\options\projects and solutions\build and run\msbuild project output verbosity' if necessary) to see if the -r:SomePath\SomeReference.dll are all correct. If not, try a similar command from the command-line, fixing the paths/references, and see if that solves the problem (and then try to reflect these corrections into the .fsproj file).

Hope that maybe helps lend some insights that may help debug this and get you unblocked...

By on 8/3/2009 4:01 PM ()

The problem is, what does "in sync with mscorlib.dll" exactly mean?

The F# project is a dll, which is itself referenced in a C# XNA project.

This is how references are set up for the F# project:
- Microsoft.Xna.Framework
- mscorlib
- System
- System.Core
All are specified using the full path to the XNA dlls for Xbox360.

The produced dll has the following manifest, retrieved using ildasm:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106

// Metadata version: v3.5.0


.assembly extern mscorlib


{


  .publickeytoken = (1C 9E 25 96 86 F9 21 E0 )                         // ..%...!.


  .ver 3:5:0:0


}


.assembly extern FSharp.Core


{


  .publickeytoken = (A1 90 89 B1 C7 4D 08 09 )                         // .....M..


  .ver 1:9:6:16


}


.assembly extern Microsoft.Xna.Framework


{


  .publickeytoken = (51 C3 BF B2 DB 46 01 2C )                         // Q....F.,


  .ver 3:1:0:0


}


.assembly extern System


{


  .publickeytoken = (1C 9E 25 96 86 F9 21 E0 )                         // ..%...!.


  .ver 3:5:0:0


}


.assembly extern mscorlib as mscorlib_4


{


  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..


  .ver 2:0:0:0


}


.assembly XBox360
{
  .custom instance void [FSharp.Core]Microsoft.FSharp.Core.FSharpInterfaceDataVersionAttribute::.ctor(int32,
                                                                                                      int32,
                                                                                                      int32) = ( 01 00 01 00 00 00 09 00 00 00 06 00 00 00 00 00 ) 

  // --- The following custom attribute is added automatically, do not uncomment -------
  //  .custom instance void [mscorlib]System.Diagnostics.DebuggableAttribute::.ctor(valuetype [mscorlib]System.Diagnostics.DebuggableAttribute/DebuggingModes) = ( 01 00 02 00 00 00 00 00 ) 

  .hash algorithm 0x00008004
  .ver 0:0:0:0
}
.mresource public FSharpSignatureData.XBox360
{
  // Offset: 0x00000000 Length: 0x0000BD36
}
.mresource public FSharpOptimizationData.XBox360
{
  // Offset: 0x0000BD40 Length: 0x0000B8C1
}
.module XBox360.dll
// MVID: {4A79E390-95C0-8466-A745-038390E3794A}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000001    //  ILONLY
// Image base: 0x032F0000

Is it OK to have mscorlib referenced twice, once using version 2.0.0.0, the other using version 3.5.0.0?
I suspect the reference to version 2.0.0.0 comes because of FSharp.Core and the reference to version 3.5.0.0 comes from the XNA mscorlib dll.

I wonder if I don't need a version of FSharp.Core built against the XNA mscorlib 3.5.0.0?

By the way, if I remove the reference to XNA's mscorlib in the F# project, the manifest only includes one reference to mscorlib (v2.0.0.0).

By on 8/5/2009 1:04 PM ()

I think possibly the problem is that you need an explicit reference to the CF version of FSharp.Core in your project file. That is, add a reference to

C:\Program Files\FSharp-1.9.6.16\CompactFramework\3.5\bin\FSharp.Core.dll

This is the FSharp.Core that should be 'in sync' with the 3.5 version of mscorlib for that platform. By explicitly referencing both FSharp.Core and mscorlib in your project, the F# compiler should warn you if anything is fishy.

By on 8/5/2009 3:06 PM ()

No luck so far :(

Adding the reference using the GUI in visual studio fails. When I click on the OK button, nothing happens.
What I did instead was to add a reference to the CF 2.0, closed visual studio and edit the fsproj file.
Surprisingly, the entry for FSharp.Core.dll had no HintPath element. I added one pointing to the 3.5 CF dll, then tried compiling again.
I got the following error:

c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(0,0): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'C:\Program\FSharp-1.9.6.16\CompactFramework\3.5\bin\FSharp.Core.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

By on 8/9/2009 2:29 AM ()

So what is the full set of references in the project file when you get that error from MSBuild?

By on 8/9/2009 1:01 PM ()

Ok, I took a couple hours this afternoon to take a close look (downloaded XNA on my home box with VS-Shell-and-Beta1, and on my work box, and tried things out).

Unfortunately, I think the answer is that in Beta1, this is 'just plain broken'. I don't think there's a way to make the F# compiler reference the XBox mscorlib DLL and generate code that can be referenced by a C# XNA app. A bug in the F# compiler prevents this from working.

The good news is, this seems to be fixed in our internal bits, so whenever Beta2 (and corresponding CTP update) finally ships, you should be able to use that.

I didn't investigate carefully the scenarios you described where e.g. you could reference the 'wrong' mscorlib from your F# project and get some things working, but then e.g. not have access to XBox-specific mscorlib features. But it seems like that may be the only workable option in the meantime (other than using an older CTP of F#).

By on 8/9/2009 4:08 PM ()

Good to know. Thanks for your time.

By on 8/10/2009 9:51 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper