Back to Questions
4.2k
views11
comments
XNA DLL references in VS 2008 Shell with F# (3.1.0.0 becomes 3.0.0.0 when building)
f#

Hi everyone

First of all, I know there is another topic about XNA on this forum, but this is about another problem (though they may be related?).

Secondly, I already opened a topic on the XNA forum, and they gave me the advice to report the issue on this forum.

This is the link to the topic on the XNA forum: [link:forums.xna.com]

I will summarize the issue. I use VS 2008 Integrated Shell SP1 (with the most recent May 2009 F# CTP), in combination with VCS 2008 Express SP1 (with XNA Game Studio 3.1). When I add XNA assembly references (XNA version 3.1) to the F# library, they automatically change to the older version 3.0, when I build the F# library.

The strange thing is that in the .fsproj file the references still are the new version.

The fact that SpecificVersion property on the reference is false, is not the cause of the problem. I do not understand why it is false by default though (in new F# projects standard assemblies references like FSharp.Core and System are also SpecificVersion false).

There is something else that's strange. I can only set the SpecificVersion to true on "Microsoft.Xna.Framework", and not on "Microsoft.Xna.Framework.Game". The IDE doesn't let me. Why the difference between those 2 XNA assembly references?

The funny thing is, after I build the F# library, I can change the value of SpecificVersion on both assembly references.

I would like to use the new XNA 3.1 features in an F# library, but at the moment I can only use 3.0 features in it.

Does anyone know how to solve this issue?

Thanks in advance.

Epic RPG Gamer

.

I don't know for sure, but I think you're probably hitting a bug in the F# project system. Briefly, in VS2010 Beta1 (and the corresponding VS2008 release, as well as all prior releases), assembly references were broken in a number of subtle ways (such as the SpecificVersion issues you're describing). Unfortunately if this is the case, I think it may be impossible to build this project from Visual Studio.

Something to try:

- make a copy of the .fsproj file

- hand-edit the .fsproj file to have the right assembly references (it may be useful to use VS to set up the working references in a C# project, and then compare the .csproj and the .fsproj, and then fix up the .fsproj)

- then invoke msbuild.exe from the command-line to build the .fsproj

I think that may work. I think also if it does work, if you open the fixed .fsproj file in VS, VS may re-mangle it back into a bad state. So you might need to keep two copies of the project, one for VS to screw up (but allow you to use VS for the editing experience), and another to use when you want to build (from the command-line using msbuild.exe).

It's also possible I've guessed wrong and there are other issues at play. But do give that a try and let me know.

By on 7/29/2009 11:51 PM ()

I tried different combinations of actions to solve the issue. Here are my findings.

You don't need MSBuild to solve the problem. You have to change the SpecificVersion property on the XNA assembly references to true, by hand-editing the .fsproj file.

Then you can build the F# library normally (via the IDE) and you can use the newest version (3.1) of the XNA assemblies.

Problems with the F# project system (when you don't use the solution explained above):

- Adding XNA assembly references, they are SpecificVersion false by default (in VCS 2008 Express the are true by default).

- By building the F# library, the XNA references change from 3.1 to 3.0. In the .fsproj text file it's still 3.1 though.

- Changing the SpecificVersion property via the IDE has strange consequences. After changing that property on one of the XNA references, you cannot change that property on other XNA references (the designer doesn't let you do it).

- But you'd think that if you can change the property via the IDE on 1 XNA reference, you'd expect that that reference stays the new version 3.1. The answer is no. Everything still changes to 3.0. But on that reference (where SpecificVersion is set to true via the IDE), the version DOES also change to 3.0 in the .fsproj text file. Very strange.

I know my English is far from perfect. I hope you understand me. It's a bit difficult to explain, because of the strange behaviour.

But, essentially, setting the SpecificVersion to true manually (in the .fsproj text file) solves the problem.

Will this bug be fixed in the final RTM version of the F# project system?

Will there be a true RTM version of F# for Visual Studio 2008 Integrated Shell SP1, or will F# always stay CTP for VS2008, and is an upgrade to the upcoming VS2010 necessary?

I hope it will be easier in the future to combine F# with XNA...

By on 7/30/2009 10:49 AM ()

Thanks for this info.

Most of these issues sound familiar. I just recently spent about a week rewriting the assembly reference code in the F# project system to (hopefully) fix all these bugs... we're using the C# project system and code base as a model, and trying to mimc its behavior exactly. So hopefully this will all be fixed in Beta2. I'm unsure we'll have time to run through all these particular XNA scenarios you mention (though I'll mention this to our test team to try to do some ad-hoc testing to scout the recent fixes here). The code for the VS2008 CTPs and the VS2010 Betas are (mostly) the same, and in this case I think you can expect to see the fix in the next 2008 CTP as well as in 2010 Beta2. The 2008 releases will always be 'just CTPs', but our intention is for them to be similar quality as the corresponding 2010 releases.

By on 7/30/2009 11:32 AM ()

There are still problems with the VS IDE to set references in the October 2009 CTP for VS 2008.

I have an F# library project which references explicitly (through using "browse" in the Add Reference dialog) to dlls in the XNA framework. The referenced items are Microsoft.Xna.Framework, System.Core and mscorlib.

Specific Version is set to True for each reference.

After running a build, references to System.Core and mscorlib are automagically changed to use other Full Path values (in C:\Windows\.NET\Framework).

Edit: Those are not just academical concerns, the resulting dll cannot be loaded by the Xbox:

An unhandled exception of type 'System.TypeLoadException' occurred in Unknown Module.

Additional information: La version de l'assembly System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089 ne peut pas être chargée par cette version du Microsoft .NET Compact Framework.

By on 11/7/2009 4:33 AM ()

I was at least able to build using msbuild from the command-line using the following project file. (This is with the October CTP and XNA.) Trying to open the project file in VS crashes VS though, sigh.

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

 

<?xml version="1.0" encoding="utf-8"?>
http://schemas.microsoft.com/developer/msbuild/2003</A>">
  
    {06FF26CD-6E7A-45A6-931F-4D62C8AE807F}
<!--    {2DF5C3F4-5A5F-47a9-8E94-23B4456F55E2};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}  -->
    {2DF5C3F4-5A5F-47a9-8E94-23B4456F55E2};{F2A71F9B-5D33-465A-A702-920D77279786}
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
      Xbox 360
      <OutputType>Exe</OutputType>
      <AppDesignerFolder>Properties</AppDesignerFolder>
      <RootNamespace>Xbox360Game2</RootNamespace>
      <AssemblyName>Xbox360Game2</AssemblyName>
      <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
      <XnaFrameworkVersion>v3.0</XnaFrameworkVersion>
      <XnaPlatform>Xbox 360</XnaPlatform>
      <XnaCrossPlatformGroupID>f9728d75-8188-45cf-82b5-91f36041c3af</XnaCrossPlatformGroupID>
      <Thumbnail>GameThumbnail.png</Thumbnail>
    
  
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Xbox 360\Debug</OutputPath>
    <DefineConstants>DEBUG;TRACE;XBOX;XBOX360</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <NoStdLib>true</NoStdLib>
    <UseVSHostingProcess>false</UseVSHostingProcess>
    <XnaCompressContent>true</XnaCompressContent>
  
  
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Xbox 360\Release</OutputPath>
    <DefineConstants>TRACE;XBOX;XBOX360</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <NoStdLib>true</NoStdLib>
    <UseVSHostingProcess>false</UseVSHostingProcess>
    <XnaCompressContent>true</XnaCompressContent>
  
  <ItemGroup>
    <Compile Include="Program.fs" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="FSharp.Core">
      <HintPath>C:\Program Files (x86)\FSharp-1.9.7.8\CompactFramework\2.0\bin\FSharp.Core.dll</HintPath>
    </Reference>
    <Reference Include="mscorlib" />
  </ItemGroup>
  <Import Project="$(MSBuildExtensionsPath32)\FSharp\1.0\Microsoft.FSharp.Targets" />
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\Microsoft.Xna.GameStudio.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
      Other similar extension points exist, see Microsoft.Common.targets.
 <Target Name="BeforeBuild">
 </Target>
 <Target Name="AfterBuild">
 </Target>
 -->
By on 11/12/2009 8:43 PM ()

Brian, is there something special with this project file? I also tried to build outside of visual studio, and succeeded, but building was never the problem.

The problem is that the resulting assembly cannot be loaded on the XBox360, because apparently it references assemblies that the XNA framework on the XBox does not like.

I have been trying many different configurations, and I must admit I am now completely lost. Instead of trying to get "something" to work, I would like to have it clear for me what I am supposed to do.

First, should I aim at building against FSharp.Core for the compact framework? It's not clear to me that this is the correct way. The framework on the XBox360 is based on the compact framework, but it's not identical.

If building for the compact framework is the way to go, the next question is which version should I use, 2.0 or 3.5?

Once that is clear, how do I actually do that in Visual Studio 2008, Visual Studio 2010 and outside of Visual Studio?

By on 11/15/2009 8:16 AM ()

Brian, is there something special with this project file? I also tried to build outside of visual studio, and succeeded, but building was never the problem.

The problem is that the resulting assembly cannot be loaded on the XBox360, because apparently it references assemblies that the XNA framework on the XBox does not like.

Hm, I think I lost track of that. I've been focusing on the "VS messes up the references" end of the issue, rather than the "even if I use msbuild, XBox still can't consume it" end.

I have been trying many different configurations, and I must admit I am now completely lost. Instead of trying to get "something" to work, I would like to have it clear for me what I am supposed to do.

First, should I aim at building against FSharp.Core for the compact framework? It's not clear to me that this is the correct way. The framework on the XBox360 is based on the compact framework, but it's not identical.

I didn't realize that. But didn't this used to 'work' a long time ago (September 2008 CTP maybe)? Back then, was the FSharp.Core compiled for CompactFramework 2.0 was used? Do you recall?

If building for the compact framework is the way to go, the next question is which version should I use, 2.0 or 3.5?

Once that is clear, how do I actually do that in Visual Studio 2008, Visual Studio 2010 and outside of Visual Studio?

Glancing at the metadata in

"C:\Program Files (x86)\Microsoft XNA\XNA Game Studio\v3.0\References\Xbox360\mscorlib.dll"

suggests to me that 2.0 is right, but I'm really not sure.

The VS aspect is looking pretty hopeless right now. Unfortunately nothing 'CompactFramework' ships in VS2010, so this is not high on our list of priorities. Back when you reported issues in Beta1, I really thought that fixing the MSBuild resolutions for resolving assemblies was 'the key bug' (for VS anyway - there was also the compiler bug about writing the correct metadata version into F# assemblies, you may recall) and would be the end of it. But now these fixes have uncovered more issues with the project flavoring mechanism.

By on 11/15/2009 1:02 PM ()

I have been trying many different configurations, and I must admit I am now completely lost. Instead of trying to get "something" to work, I would like to have it clear for me what I am supposed to do.

First, should I aim at building against FSharp.Core for the compact framework? It's not clear to me that this is the correct way. The framework on the XBox360 is based on the compact framework, but it's not identical.

I didn't realize that. But didn't this used to 'work' a long time ago (September 2008 CTP maybe)? Back then, was the FSharp.Core compiled for CompactFramework 2.0 was used? Do you recall?

Yes, it worked with the previous version. I did not have to do anything special, just create a standard F# lib project, add a reference to the XBox XNA framework assemblies, and everything went fine. The trouble started when I tried to explicitly link against mscorlib from XNA in my F# project.I guess that XNA Studio has some magic to make 3rd party assemblies usable in an Xbox XNA project.The problem is that this magic no longer seem to work. I could ask on XNA Creators club forums, the guys behind the XNA framework are active there.EDIT: Does FSharp.Core.dll try to load System.dll version 2.0 dynamically? It's just a wild guess on my part, but if it does that, and if the XNA magic happens at build time, that might explain why the XBox complains about System.dll. The build-time magic would probably not be able to handle run-time dynamic assembly loads.

If building for the compact framework is the way to go, the next question is which version should I use, 2.0 or 3.5?

Once that is clear, how do I actually do that in Visual Studio 2008, Visual Studio 2010 and outside of Visual Studio?

Glancing at the metadata in

"C:\Program Files (x86)\Microsoft XNA\XNA Game Studio\v3.0\References\Xbox360\mscorlib.dll"

suggests to me that 2.0 is right, but I'm really not sure.

The VS aspect is looking pretty hopeless right now. Unfortunately nothing 'CompactFramework' ships in VS2010, so this is not high on our list of priorities. Back when you reported issues in Beta1, I really thought that fixing the MSBuild resolutions for resolving assemblies was 'the key bug' (for VS anyway - there was also the compiler bug about writing the correct metadata version into F# assemblies, you may recall) and would be the end of it. But now these fixes have uncovered more issues with the project flavoring mechanism.

I will try with a good old makefile or a script to avoid any problem related to msbuild, and report how far I got.

By on 11/17/2009 1:43 PM ()

After asking on the XNA Creator's club forum, I managed to get it working.
The right way of doing things is to reference System*.dll and mscorlib from the XNA framework for the XBox and FShap.Core.dll for the compact framework 2.0.
I have to use a batch script to build my library, as msbuild and visual studio 2008 override my choice of dlls to use those for the PC platform.

The command line I used:

"C:\Program Files\FSharp-1.9.7.8\\bin\fsc.exe"

-o:obj\Release\XBox360.dll --standalone --noframework --define:TRACE

--optimize+ --tailcalls+ -r:"C:\Program

Files\FSharp-1.9.7.8\CompactFramework\2.0\bin\FSharp.Core.dll"

-r:"C:\Program Files\Microsoft XNA\XNA Game

Studio\v3.1\References\Xbox360\Microsoft.Xna.Framework.dll"

-r:"C:\Program Files\Microsoft XNA\XNA Game

Studio\v3.1\References\Xbox360\mscorlib.dll" -r:"C:\Program

Files\Microsoft XNA\XNA Game

Studio\v3.1\References\Xbox360\System.Core.dll" -r:"C:\Program

Files\Microsoft XNA\XNA Game Studio\v3.1\References\Xbox360\System.dll"

--target:library --warn:3 --warnaserror:76 --fullpaths --flaterrors

<your F# source files here>

By on 11/19/2009 1:51 PM ()

I am a bit disappointed to see the same problem is still in F# 1.9.9.9. It is very frustrating to see Visual Studio second-guess me and override my choice of System.dll and System.Core.dll. Oh well, I'll just keep going with my batch script, then.

By on 3/5/2010 10:55 AM ()

Okay thanks. I wish the F# team the very best, developing the next CTP and Beta of F#.

F# rocks and using the language for making XNA games is more fun than using C#.

Epic RPG Gamer

By on 7/30/2009 11:56 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