Type unification issues across different .NET profiles for type providers

[KevinRansom]

Originally opened at CodePlex bylatkin

Originally logged on github here.

The immediate issue is that types used by generative type providers are not being unified properly with types used in portable class libraries, resulting in erroneous compile errors "Static linking may not use assembly that targets different profile."

Attached is a repro project which fails to build with error "Static linking may not use assembly that targets different profile". It requires a SQL DB named "Test" with the following table:

USE [Test]
GO

/****** Object:  Table [dbo].[TweetSharp_Tweet]    Script Date: 10-Jan-14 20:45:24 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[TweetSharp_Tweet](
       [ID] [bigint] NOT NULL,
       [InReplyToScreenName] [nvarchar](2000) NULL,
       [InReplyToStatusId] [bigint] NULL,
       [InReplyToUserId] [bigint] NULL,
       [IsFavorited] [bit] NOT NULL,
       [IsPossiblySensitive] [bit] NULL,
       [IsTruncated] [bit] NOT NULL,
       [Language] [nvarchar](50) NULL,
       [Location] [nvarchar](2000) NULL,
       [Place] [nvarchar](2000) NULL,
       [RawSource] [nvarchar](max) NULL,
       [RetweetCount] [int] NULL,
       [RetweetedStatus] [nvarchar](2000) NULL,
       [Source] [nvarchar](2000) NULL,
       [Text] [nvarchar](2000) NULL,
       [TextAsHtml] [nvarchar](2000) NULL,
       [TextDecoded] [nvarchar](2000) NULL,
       [User_ID] [bigint] NULL,
       [User_FollowersCount] [bigint] NULL,
       [Users_RetweetCount] [bigint] NULL,
       [Author_ScreenName] [nvarchar](2000) NULL,
       [CreatedDate] [datetime] NOT NULL,
CONSTRAINT [PK_TweetSharp_Tweet] PRIMARY KEY CLUSTERED 
(
       [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

When "newrec" is from SqlDataConnection type provider, representing SQL table with CreatedDate column of type [datetime], and "twt" is from LinqToTwitter portable library, the following line causes static linking error:
newrec.CreatedDate <- twt.CreatedAt

Commenting out this line works around the problem. Adding back just the below line will cause repro again:

let foo = twt.CreatedAt

Commentary from Vlad: I’d say that current behavior is a very crude workaround for the fact that generated types obtained from type providers are not rescoped but rather merged as is. Consequences of this is hard to predict, a few that I’ve seen were crashes on the late stages of the codegen when compiler tried and failed to find matching mscorlib types in System.Runtime and vice versa.

File Attachement

[dmitry-a-morozov]

Is this going to be solved in v4?
I'm hitting this issue when I use xUnit.NET v2.

[CumpsD]

When you want to use Serilog and FSharp.Configuration (SharpYaml) together, you run into this as well

[CumpsD]

Here is a minimal repro:

https://github.com/CumpsD/staticlinking-bug

Serilog is profile 259

FSharp.Configuration is a TP, uses SharpYaml, SharpYaml is profile 136

At a certain point, the compiler runs into https://github.com/CumpsD/staticlinking-bug/blob/master/src/bug/Bug.fs#L13 and tries to access .Properties which is an IReadOnlyDictionary, when it hits https://github.com/fsharp/fsharp/blob/master/src/fsharp/fsc.fs#L1673 the name is System.Runtime and isMscorlib is true causing it to blow up with Static linking may not use assembly that targets different profile.

[dsyme]

@CumpsD Many thanks for the minimal repro (long ago!). I've submitted a fix to this bug.

[kurtschelfthout]

Can we close this now? (for folks like me going over bugs trying to fix, would be nice to close things, thanks!)

[dsyme]

Yes

[sergey-tihon]

Am I right that if I still see this issue on AppVeyor
https://ci.appveyor.com/project/sergey-tihon/swaggerprovider/build/0.0.1.335#L391
the only solution it to use newer F# compiler (VS2017 image)?

and generative TP that want to support full .net and pcl (xamarin) should provide assemblies compiled for both frameworks, because pcl assemblies references from full .net may break compilation in VS2015 and lower?