3
votes

I've developed a simple and small Universal Windows App that uses EF7 and SQLite. It compiles and runs smoothly when the option "Compile with .NET Native tool chain" is unchecked.

If I check the option "Compile with .NET Native tool chain", I get the following compilation error:

Error Type 'System.MarshalByRefObject' was not included in compilation, but was referenced in type 'Microsoft.Data.Entity.Design.OperationExecutor'. There may have been a missing assembly.

After this there's a lot of other errors, but I believe that solving this one will also take care of the rest.

Does anyone know how to solve this?

1
Just add the type to Default.rd.xml and try again.Hans Passant
How do I do that and where?Daniel
Come on man I'm starting with .NET and C#. Nobody's born knowing everything. Since you know hot to do it I believe that would be no problem in telling me. I've typed in google already and found that this file is in my project's properties folder. The thing is I dont know how to add "System.MarshalByRefObject" reference.Daniel
Exact same problem hereAymenDaoudi

1 Answers

5
votes

I presume what has happened is that you're using a library that isn't targeting the .NET surface area available to UWP. The surface area for UWP is the set of APIs called .NET Core, you can see the source here: http://www.github.com/dotnet/corefx. Most likely you'll need a newer version of EF... although I know they've had some other issues with our ahead of time compilation strategy (see: https://github.com/aspnet/EntityFramework/issues/3603). We're continuing to work with them to get it sorted out and are hopeful that EF will be in a great place by Update 2 sometime in March.

The reason you only see this with .NET Native is because the compiler is walking your entire application at compile time in order to generate native code for everything that it thinks you're going to call. It happens to notice that this type is unavailable and correctly errors out. I presume you don't actually call this code path in your application because it would produce a similar error on CoreCLR... it would just happen at runtime and not compile time.

If you don't actually need this type (and everything else you need also doesn't need this type etc etc), it's possible that removing this directive from your application will allow the tree shaker to eliminate this type from your application before things go awry:

    <Assembly Name="*Application*" Dynamic="Required All" />

This directive causes all of the types in your application and the non framework libraries you reference to be rooted and thus unable to be shaken away. Having this directive by default makes our analysis easier and keeps most folks from having to know too anything about our analysis engine. It's possible that removing this can help you avoid the issue.

Let me know if that works out or if you have any other questions. We always love to get feedback and provide some support at [email protected].