Then, open VS Code and go to settings. To make this change for all projects, click User. To change for just this project (which I’d recommend) click Workspace. This will allow you to do your regular .Net development using the built-in mono (and eventually .Net Core).
Migrating a .Net 4.x Console Application to .Net Core
I finally got the server side of Winds of Paradise running in .Net Core! I thought I’d share how it did in, in hopes that it might help you do the same. As cool as Mono is, I’m totally psyched to have all my C# code running on Microsoft’s .Net under Centos Linux!
You can also find instructions there on how to install .Net Core onto wherever your code will be hosted.
Once everything is installed (block out a good hour for this), I opened my existing solution in Visual Studio.
To the solution, I then added another project and chose the type: Console Application (.Net Core)
Next, open that project and use the NuGet Manager to install any packages that you are using in your .Net 4.x project. For me, this was npgsql and Newtonsoft.JSON.
Once the new project is created, copy over all of your .cs files from your original project to the new .Net Core version.
Hit build, and start working on replacing any .Net 4.x functionality that is not available in .Net Core.
What I did was make corrections in the .Net Core version and then replicate those changes in the .Net 4.5 version. This way, I could build and run the old version with minor changes to prove the changes worked, rather than changing *everything* and trying to debug the .Net Core version. This worked, since the .Net 4.x encompasses everything .Net Core does.
Once you’ve worked out all of the bugs, copy all of your code over to whatever box your running on .Net Core on (Windows, Linux, MacOS, etc.).
Open a shell, cd in the folder with project.json and run:
That’s it! .Net will download necessary packages from nuget, compile, and run.
Here’s some of the classes I had to find workarounds for:
The .Net Core version of this object only has async methods for GetRequestStream and GetResponse. You’ll have to move to GetRequestStreamAsync and GetResponseAsync, which also means having your methods return Task instead of void
Also, the .Net Core version does not have HttpWebRequest.ContentLength when doing a POST. So far, simply removing it seems to work fine in both .Net 4.5 and .Net Core.
I’m guessing this could probably be made to work with .Net Core fairly easily, but moving NpgsqlDataAdpater usage to NpgsqlDataReader for better database efficiency has been on my TODO list for quite a while anyway.
I found a great resource for setting up json configuration files at: https://csharp.christiannagel.com/2016/08/02/netcoreconfiguration/
A couple notes:
1) I had previously been targeting .Net 4.5. I needed to target 4.5.1 in order to install Microsoft.Extensions.Configuration
2) If you create appsetttings.json in your .Net 4.5 project 1st, make sure to create appsettings.json in your new .Net Core project, DON’T COPY it from from the .Net 4.5.1 one. Creating it new sets it as a “Content File”
This was a tricky one. System.Timers.Timer allows easily add/subtracting events from occurring on the timer with Elapsed += [function]. This allowed me to have a couple of static timers that any other object could add events to.
The only alternative in .Net Core is the System.Threading.Timer. This timer is much less sophisticated. It can only accept one function to run at each tick, and this function cannot be changed. My workaround was to implement a separate timer for each object that needed one. I’m hoping this does not increase resource consumption. Hopefully a better timer alternative will work its way int nuget, I didn’t see anything that looked promising at the moment.
If you recently upgraded to Mono 4.0 and you use DataTables to return SQL results (in my case from Postgresql), you may have received a heart attack similar to mine when you were bombarded with the error:
I was working on getting Postgresql, Visual Studio Remote Debugger, and PHP running on Server 2012 R2 so that I can up my debugging-fu, rather than just relying on Console.WriteLine.
Ran into some DLL hell trying to get npgsql working. I saw NuGet mentioned while Binging for solutions, so I figured I’d give it a try. Where has this been all my coding life?
A few clicks, and remote debugging is up and running. I even copied the compiled files over to my production box, and everything is working fine in Centos on Mono as well. What a great way to spend a Friday morning off!
It’s something drilled into every MBA, day after day. It’s a simple mantra, but one easily forgotten as excitement around a project builds. I am always tempted to re-invent the wheel, just to see what kind of wheel I can come up with.
But, when you have a goal in mind, remember: you don’t need to roll your own JSON library, host your own Git repository, code a game engine from scratch. Keep it simple, and focus on what you do best.
PS: Also fight the urge to recode your Java app in C# because Visual Studio 2013 is all free now. Fight it. You can do it!
It couldn’t hurt to see how Mono runs in Centos these days though…