.Net Core is starting to look like the future for .Net server side development, and I'm already in a situation where I'm obligated to port code to Core and write new code to be core-compatible. The obstacle is typically third party library support; .Net is rarely ever the issue. DataObjects.Net is the third-party library that creates the biggest problem, as it's the only one that doesn't support Core that I can't port to Core myself.

While lack of DataObjects.Net on Core isn't a blocker for me personally ... yet, it would simplify my life if I could move everything over to Core sooner rather than later. I'm sure I can't be the only one headed towards this kind of transition.

It would be a benefit if DataObjects.Net were available for Core, and now we live in a topsy turvy world where SQL Server is available for Linux, we could even have the full suite of database support there that we have on Windows.


  • Does DataObjects.Net have a roadmap for porting to Core? (Windows, Linux and OSX).

  • Are there likely to be any major obstacles to creating a version for Core?

  • I imagine that it would make sense for some things to change, for example, splitting the configuration data from the application config file into a file of its own? Are such changes being considered?

  • Would it be practical for an early adopter to port the source themselves? Particularly if they only needed a single DB driver to work?

  • Have you already experimented with porting to Core, and found the major obstacles were the license system, MSBuild integration, configuration data, etc., rather than the heart of the run-time code?

asked May 30 at 03:37

Peter%20Wake's gravatar image

Peter Wake
5223


3 Answers:

Hello Peter Wake

Yes, we have plans to port DataObject.Net to .Net Core.

Answering your questions I want to say following

"Does DataObjects.Net have a roadmap for porting to Core? (Windows, Linux and OSX)"

Unfortunately, we don't have exact time of release. Now we're implementing two very important improvements, which distracted us from experiments with .Net Core. What I can say for now after my experiments with .Net Core is that for the first time it will be Windows only assemblies because we still don't know how to perform certain things on Linux and Mac platforms.

"Are there likely to be any major obstacles to creating a version for Core?"

Yes, we have some obstacles for us like changes in reflection (we use it a lot) and serialization. I have heard that there are some issues with DateTime support on non-Windows platforms. Also we have MSBuild-based building process and that's why json project configurations might be a problem.

"I imagine that it would make sense for some things to change, for example, splitting the configuration data from the application config file into a file of its own? Are such changes being considered?"

Of course we will have to change some things. We will need async/await support for sure. I personally think that there is no sense porting DO without this feature supported. Also we will probably do some API changes, maybe get rid of some legacy code. I'm not sure about configuration file, we will tent to follow trends of .Net Core framework and if configuration files are obsolete in it we will probably use something which is up-to-date.

"Would it be practical for an early adopter to port the source themselves? Particularly if they only needed a single DB driver to work?"

First, we will try to port DO as it is, probably first release will have minimum changes in APIs, we don't know it yet and will see it further. I think it will contain MS SQL Server provider only, because it has client library with .Net Core support. Then we will analyze which RDBMSs also have .Net Core support. So I think yes, early releases have very high chances to be convenient for development, not for production.

"Have you already experimented with porting to Core, and found the major obstacles were the license system, MSBuild integration, configuration data, etc., rather than the heart of the run-time code?"

Yes, we have. We used special tool provided by Microsoft to understand .Net Core compatibility level of our solution and the results fairly promising. Main expected obstacles are our licensing and weaving mechanisms, assembly building process. Speaking of Windows platform, we won't expect serious issues with licensing and weaving, but Mac and Linux platform is unknown for us and it will be real problem we don't know how we will solve this.

As I mentioned previously, we have certain MSBuild-bases assembly building process. Since my experiments .json files have been replaced with .csproj files and it might solve some potential building problems but we haven't played around the latest release yet so I can't say whether it does.

I hope I answered your questions properly. If not please welcome to comment my answer.

answered May 31 at 07:00

Alexey%20Kulakov's gravatar image

Alexey Kulakov
52715

Disclaimer: this is not an official answer from DO team, though it's an answer from the company's shareholder who's also interested in seeing this feature implemented.

Quite likely we'll start working on this closer to the point .NET Core 2.0 is going to be released. .NET Core 1.1 is very good, but the compatibility with .NET 4.6 is still not quite there. And based on what's known about .NET Core 2.0 now, it might be way easier for DO team to provide .NET Core support for .NET Core 2.0 rather than 1.1.

So we'll definitely review this closer to the .NET Core 2.0 release, or right after it. Overall, we definitely want this to happen, and personally I think .NET Core is amazing. It totally makes sense to support it, and moreover, probably that's the only meaningful future for .NET.

answered May 31 at 15:16

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Hopefully, you'll find that the new .csproj format makes it practical to port most of your MSBuild code. I have some fiddly MSBuild stuff, and it went into the new .csproj format with very few changes; it just pushed me to clean up some targets that ran too eagerly under incremental.

Consider looking at how SimpleInjector handles support for 4.5 and .NET Core, as they overcome the reflection differences with some simple extension methods. I was able to build SimpleInjector under 4.62 without much effort, so there's definitely a path from 4.X => 1.4

(Jun 14 at 02:30) Peter Wake Peter%20Wake's gravatar image

Yes, we know .NET Core is already quite solid. We mostly postpone this because there are < 3 months till Core 2.0 release date, so prob. it doesn't make a lot of sense to invest a lot into porting right now, assuming most of these efforts are going to be wasted (of course, if what's promised on .NET Core 2.0 compatibility is true).

(Jun 19 at 02:46) Alex Yakunin Alex%20Yakunin's gravatar image

Any news on the timeframe for supporting .NET Core 2.0?

answered Nov 01 at 04:59

Marco's gravatar image

Marco
22161618

We are actually on the way to get DataObjects ported to .Net Core 2.0. We've started some time ago.

(Nov 02 at 05:59) Alexey Kulakov Alexey%20Kulakov's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA