Deploy .NETCoreApp to Azure Service Fabric

Should be obvious how to do this.

Either it is not obvious or I am really slow (yep, left myself open).  So you can’t wait to use the .NET Core 1.0.x platform and you are a glutton for punishment like me.  You want to get your brand new .NETCoreApps up on Azure Service Fabric.  Well it is not exactly clear how to do this and the Visual Studio templates don’t help here.

Note: Visual Studio 2015 Update 3 with latest tooling as of this post date do have an ASP.NET Core template for Azure Service Fabric.  But ASP.NET Core is not a .NETCoreApp.

Why do you want to do this? In my case, my company has been steadily porting our aging .NET Framework libraries to the new .NET Core.  I do not want to go back to the old .NET Frameworks.  Microsoft just informed we developers about the new .NET Standard 2.0 here.  If you were around back in the late 1990’s and very early 2000’s you likely struggled with the transition from ASP Classic to .NET 1.0/1.1.  If that wasn’t enough .NET 2.0 quickly followed.  There was no direct port from the 1.1 to 2.0 back then.  It seems that we should have learned by now that 1.x anything is just a trial run.  So we all have deja vu with .NET Standard 2.0.  Yeah this time its going to be better…  My fingers are crossed.

The Nitty Gritty

So I promised to tell you how to deploy your .NETCoreApp to Azure Service Fabric.  The first thing to know is this is a “guest executable” in service fabric. Read this article for background here “Deploy a Guest Executable to Service Fabric”.  I expect that you have a working .NETCoreApp that you want to run in Azure Service Fabric ready and tested locally.  The best way to do the deployment is to use Visual Studio as the article describes.  But you must do a little prep-work first for the .NETCoreApp to make it work.

It is utterly simple. In Visual Studio with your desired .NETCoreApp, right-click the project.  From the context menu click “Publish…” and use “File System” as the target location.  Make a note where you put your output.  The default is bin/release.  This causes Visual Studio to gather all the files necessary to run your application into a single folder.  The current Visual Studio tooling does not do this for .NETCoreApp when publishing to the fabric.

Now that you have a complete package you are ready to create your Azure Service Fabric guest executable.  From Visual Studio create a new Service Fabric project and select the guest executable template.  A configuration dialog appears. In the required Code Package input field browse to the folder discussed above and select it.  If you are still developing your .NETCoreApp select the “link” to your code and also choose “CodeBase” for your work folder. From here you publish your .NETCoreApp to your Azure Service Fabric (cloud or local).

Parting Shots:

If you are still developing your .NETCoreApp you will have to repeat the publish cycle every time you want to test in the fabric.

The clue to the problem was found in the Microsoft documentation article mentioned above.  The tip off was this statement:

Service Fabric does an xcopy of the content of the application root directory…

That simple statement and the word “xcopy”.  The ah-ha! moment.  All the reference libraries are not present in the bin folder!  Visual Studio keeps all the standard libraries in a common location on the local computer.

I hope this saves you a bunch of time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s