.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.
|
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. |
Hello guys, We are almost ready to publish .net Standard version it still has some issues but major functionality works, I thing we will do it until the end of this week or at first half of the following. When it happens I'll make a post with detailed information about its state in our official blog. Stay tuned. Update .Net Standard version is in Nuget. I have published a post about this release in our blog |