Conflicts between different versions of the same dependent assembly in FSharpx.TypeProviders #91

Closed
forki opened this Issue Sep 19, 2012 · 11 comments

Projects

None yet

2 participants

@forki
Member
forki commented Sep 19, 2012

The following is from a mail I got via nuget.

"I have run into a compiler warning with a version of this package used in F# WPF Application templates.

It says "Found conflicts between different versions of the same dependent assembly"
I downloaded this program called assembly spy (asmspy.exe) which checks for conflicts, and it turns out there are 5 versions of "FSharpx.TypeProviders" in the package on the NuGet website:
4.0.0.0, 2.0.0.0, 4.3.0.0, 14.0.0.0, 1.6.30.0

I got these references from installing package "1.6.30.0 Thursday, September 13, 2012" directly from the "Package Manager Console" in Visual Studio 2012.

Here is a list of all the references (the app name is "FSTest2": a console application which installs the package and lifts the code and xaml from your "WPFSample" app):

Reference: mscorlib 4.0.0.0 by FSharp.Core 4.0.0.0 by FSharpx.Core 4.0.0.0 by FSharpx.TypeProviders 2.0.0.0 by FSharpx.TypeProviders 4.0.0.0 by FSTest2 Reference: System.Core 4.0.0.0 by FSharp.Core 4.0.0.0 by FSharpx.Core Reference: System 4.0.0.0 by FSharp.Core 4.0.0.0 by FSharpx.Core 4.0.0.0 by FSharpx.TypeProviders Reference: System.Numerics 4.0.0.0 by FSharp.Core Reference: FSharp.Core 4.3.0.0 by FSharpx.Core 4.3.0.0 by FSharpx.TypeProviders 4.3.0.0 by FSTest2 Reference: FSharp.PowerPack 2.0.0.0 by FSharpx.Core Reference: Microsoft.Office.Interop.Excel 14.0.0.0 by FSharpx.TypeProviders Reference: System.Xml 4.0.0.0 by FSharpx.TypeProviders Reference: System.Xml.Linq 4.0.0.0 by FSharpx.TypeProviders Reference: PresentationFramework 4.0.0.0 by FSharpx.TypeProviders 4.0.0.0 by FSTest2 4.0.0.0 by FSTest2 Reference: System.Configuration 4.0.0.0 by FSharpx.TypeProviders Reference: FSharpx.Core 1.6.30.0 by FSharpx.TypeProviders Reference: PresentationCore 4.0.0.0 by FSTest2 Reference: FSharpx.TypeProviders 1.6.30.0 by FSTest2

AsmSpy http://mikehadlow.blogspot.ca/2011/02/asmspy-little-tool-to-help-fix-assembly.html"

@forki
Member
forki commented Sep 19, 2012

At the moment I'm trying to build the TypeProviders package with .NET 4.0 - let's see if this works.

@forki forki added a commit that referenced this issue Sep 20, 2012
@forki forki Copy the FSharp.Core.dll directly into the package - the nuget depend…
…ency doesn't work. - issue #91
3a76960
@forki
Member
forki commented Sep 20, 2012

I managed to make the FSharpx.TypeProviders work with .NET 4.0. It seems we don't need to create a .NET 4.5 package any longer.

I also tried to add the FSharpx.Core package as a to the FSharpx.TypeProviders package. But this doesn't work. In this case the type provider architecture can't find the right FSharpx.Core.dll. (The nuget installation process seems to be OK)

If I remove the package dependency and add the FSharpx.Core.dll directly into the FSharpx.TypeProviders package everything works fine. At least the steps from http://www.navision-blog.de/2012/03/22/wpf-designer-for-f/ are working again.

Any ideas?

/cc @mausch @panesofglass @dsyme

@forki
Member
forki commented Sep 20, 2012

I got help from Don. I'll use ILMerge to solve this.

@forki
Member
forki commented Sep 20, 2012

A little background: A type provider is a stand alone tool. The nuget package dependency makes no sense. I didn't realised this before.

@ovatsus
Contributor
ovatsus commented Sep 20, 2012

Does that mean that a type provider can never depend on any non system assembly?

@forki
Member
forki commented Sep 20, 2012

As I understand it: This means you have to put everything the type provider needs into the same folder or into the GAC.

(You could also load stuff dynamicly from your type provider code)

@ovatsus
Contributor
ovatsus commented Sep 20, 2012

Ok, so that was why when I tried to move the json parser to FSharp.Core, the type provider stopped working, I only put it as a nuget dependency

@forki
Member
forki commented Sep 20, 2012

Exactly. I'm trying to solve this now.

@forki
Member
forki commented Sep 20, 2012

seems to work

@forki forki closed this Sep 20, 2012
@ovatsus
Contributor
ovatsus commented Sep 20, 2012

Great. Do you want to try to move the json stuff back to fsharp.core? It's genuinely useful outside of the type provider

@forki
Member
forki commented Sep 20, 2012

Yep. It's still not that easy, but I think I'll have it tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment