When leaked online and then subsequently announced by Microsoft the next day, I was ecstatic to hear that I might finally be able to cease firing up a Windows VM every time I wanted to debug or develop against our existing Web API. Installation and use had its up and down moments, but overall: I am still very excited.
My task was simple: see if I could use the new Visual Studio (VS) preview on my MacBook to create a reporting bridge between a NoSQL database and an internal SQL Server. This would mean connecting to Google Firebase using our existing c# code and gently massaging and transforming data as it is then inserted into SQL while handling any crazy data abnormalities that might come up.
What I quickly discovered is that this is really an improvement on the Xamarin IDE and, as a former user, it appears to have grown up quite a bit. Installation was a combination of easy and puzzling. While you can definitely install the
VS preview no problem, it doesn’t come with the latest .NET Core (1.1 as of now) by default. But no big deal, you head over to the .NET Core site (https://www.microsoft.com/net/core) and it will walk you through easy installation from there (about 5 semi-steps on my Mac). Once that is done, you are all set to create a new .NET Core project that will run pretty much everywhere. Well, that is, after you update your Nuget package to support the latest .NET Core. Seriously. But I can forgive that because it’s a preview and this is all new on both sides.
Next I copied some existing classes from the Web API because, you know, code reuse and stuff. For this I decided a simple console app would do the trick so I could run it using a Task Scheduler or cron job of sorts. I also decided to snag the Web.config and use some of the keys from it in the new project. This is really the only place I started to run into problems and it isn’t even directly related to Visual Studio.
According to this link (https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration) the world of configuration has changed while I wasn’t looking. Moving forward, configuration elements will be strongly-typed and no longer be read from the longstanding “config” file. I saw this as another challenge and a chance to see what I could get away with in this brave new world. So, I whipped up a new singleton class to read the now-dated Web.config file I stole from the other project and read it into a dictionary so I could still access my key/value pairs just I had done with ConfigurationManager for so long. Impressively, this worked very well and with little issue.
Next was the real main task: transferring the data from Firebase to SQL Server. Again, this was no problem. I already had the Firebase piece taken care of from pre-existing code. This transferred over effortlessly. I was able to add the Nuget package for System.Data.SqlClient namespace access and was able to knock out the basics in no time.
What about web content, right? Much like VS on Windows, a web/application server is baked into this and will fire up a browser and redirect it to the specified URL as needed. In my playing with this, I found that I will have to dig into URL rewrite techniques since they didn’t appear to work correctly out of the box with the Web API we have targeting .NET 4.5, but this could just be something I am forgetting to do.
This thing is awesome. It delivers well on the promise even in preview status. I am thrilled to see the continuation of this effort and the many other solid works that are bringing our dependencies on specific platforms for development to an end.