In .net framework we can specify the protection level for a class used in WCF as such:
[System.ServiceModel.MessageHeaderAttribute(ProtectionLevel=ProtectionLevel.None)]
public ISomeInterface SomeObject;
However, in .net core, there does not seem to be an option to specify the protection level for a MessageHeaderAttribute. This is a problem as the WCF service our organisation needs to submit information to requires that ProtectionLevel to be set to None for the object.
Can this be achieved in .net core?
I have an ASP.NET Core web app and a Windows Service that both access the same database. I am using Entity Framework Core as an ORM. I would like to be able to create a library package that encapsulates all data access (ie. a Repository) and can be shared by both the web app and the service.
Entity Framework Core appears to only be supported in DNX applications, and Windows Services, as standard Windows applications, cannot reference DNX projects. Is there any way of creating a DNX Windows Service, or another approach that would work?
Creating a standard windows class library with EF 6.x is not an option as the Repository has already been written in EF Core.
Just discovered my mistake, Entity Framework Core is supported in standard windows projects, so it looks like I have my solution: create a Repository class library that accesses the database using EF Core and reference it from both the ASP.NET Core and Windows Service apps.
I need ODP.NET (Oracle Data Providers for .NET) on .NET Core but can't find anyway to make it work.
When I reference OracleConnection or OracleCommand classes, the project needs System.Data assembly which I can't find in .NET Core.
So isn't there any solution to use ADO.NET on .NET Core?
The System.Data.Common contract is available for providers to start implementing against. So far, the only implementations on .NET Core that I know of are System.Data.SqlClient and Microsoft.Data.Sqlite.
Just upgraded a .NET 4.5 WCF Service, which also has an OData service to use EF 6. The OData service was of course working prior to the upgrade. Now, when attempting to query the OData service or even just browse to it from Visual Studio 2012, I get the following Request Error:
The server encountered an error processing the request. The exception message is 'Expression of type 'System.Data.Entity.Core.Objects.ObjectContext' cannot be used for return type 'System.Data.Objects.ObjectContext''. See server logs for more details.
The exception stack trace is:
at System.Linq.Expressions.Expression.ValidateLambdaArgs(Type delegateType, Expression& body, ReadOnlyCollection`1 parameters)
at System.Linq.Expressions.Expression.Lambda[TDelegate](Expression body, String name, Boolean tailCall, IEnumerable`1 parameters)
at System.Data.Services.Providers.DbContextHelper.CreateDbContextAccessor(Type type)
at System.Data.Services.Providers.DbContextHelper.GetDbContextAccessor(Type type)
at System.Data.Services.DataService`1.CreateMetadataAndQueryProviders(IDataServiceMetadataProvider& metadataProviderInstance, IDataServiceQueryProvider& queryProviderInstance, Object& dataSourceInstance, Boolean& isInternallyCreatedProvider)
at System.Data.Services.DataService`1.CreateProvider()
at System.Data.Services.DataService`1.HandleRequest()
at System.Data.Services.DataService`1.ProcessRequestForMessage(Stream messageBody)
at SyncInvokeProcessRequestForMessage(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
The ODataLib is 5.6, EF is 6.0.1, the WCF Data Services Server is 5.6.
This issue did not help. I have done everything from here as well with no luck. I have no references to System.Data.Entity. What can I do to get past this?
Use the WCF Data Services Entity Framework Provider.
See Using WCF Data Services 5.6.0 with Entity Framework 6+ for more information.
Using WCF Data Services 5.6.0 with Entity Framework 6+
And now for some exciting news: you can finally use WCF Data Services with Entity Framework 6+! Today we are uploading a new NuGet package called WCF Data Services Entity Framework Provider. This NuGet package bridges the gap between WCF Data Services 5.6.0 and Entity Framework 6+. We were able to build this provider as an out-of-band provider (that is, a provider that ships apart from the core WCF DS stack) because of the public provider work we did recently.
Upgrading an existing OData service to EF 6
If you are upgrading an existing OData service to Entity Framework 6 or greater, you will need to do a couple of things:
Install the WCF Data Services Entity Framework Provider NuGet package. Since this package has a dependency on WCF Data Services 5.6.0 and Entity Framework 6 or greater, some of the other NuGet packages in your project may be upgraded as well.
Replace the base type of your DataService. For EF 5 or below, your data service should inherit from DataService<T> where T is a DbContext or ObjectContext. For EF 6 or greater, your data service should inherit from EntityFrameworkDataService<T> where T is a DbContext. See What’s the difference between DataService and EntityFrameworkDataService below for more details.
Creating a new OData service with EF 6
If you are creating a new OData service and would like to use Entity Framework 6 or greater, you will need to follow similar steps:
Create your new project. I typically use an ASP.NET Empty Web Application for this, but you can use whatever you want. Note that if you do use the empty template, you may need to create an App_Data folder for Entity Framework to work properly with LocalDB.
Install the WCF Data Services Entity Framework Provider NuGet package. Since this package has a dependency on WCF Data Services 5.6.0 and Entity Framework 6 or greater, some of the other NuGet packages in your project may be upgraded as well.
Add a new WCF Data Service. It’s best if you ensure that your tooling is up-to-date as we occasionally fix bugs in the item template. Our latest tooling installer was released with WCF DS 5.6.0. It can be downloaded here.
Replace the base type of the DataService that was generated by the item template. For EF 6 or greater, your data service should inherit from EntityFrameworkDataService<T> where T is a DbContext. See What’s the difference between DataService and EntityFrameworkDataService below for more details.
What’s the difference between DataService<T> and EntityFrameworkDataService<T>?
Historically the WCF DS stack required all WCF DS-based OData services to inherit from DataService<T>. Internally, the data service would determine whether the service should use the in-box EF provider, the in-box Reflection provider, or a custom provider. When we added support for EF 6, we utilized the new public provider functionality to allow the provider to ship separately. This will allow us, for instance, to use WCF DS 5.6.0 with either EF 5, 6, or some future version. However, the new public provider functionality comes with a little bit of code you need to write. Since that code should be the same for every default EF 6 WCF DS provider, we went ahead and included a class that does this for you. EntityFrameworkDataService<T> inherits from DataService<T> and implements all the code you would need to implement otherwise. By shipping this additional class, we literally made the upgrade process as simple as changing the base type of your service.
Note for others; this is still a pre-release NuGet package as of June 2014. You need to include the -Pre option to install:
PM> Install-Package Microsoft.OData.EntityFrameworkProvider -Pre
Lets say I build an Service Layer wich deals with POCOs coming out of an repository. The Repository is aware of the EF 4.0 and deals with POCO generation and so on. But that does also mean that my Repository will have a .NET 4.0 dependency and so my Service Layer which consumes the Repository will also have a .NET 4.0 dependency...even if its dealing only with POCOs and has no clue about the Entity Framework at all. Is there any way to work around this?
You could expose your EF entities using a WCF service - your server-side would be .NET 4 specific, obviously - with EF 4, .NET 4, WCF 4 - but the consumer / client doesn't have to be - if can be anything from any other .NET platform to PHP to Ruby to whatever might be calling your service.