Type unification issues across different .NET profiles for type providers

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

[dsyme]

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

[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.