Deploying a C# app through pip

by Rob Galanakis on 28/05/2014

“If we bundle up this C# application inside of a Python package archive we can deploy it through our internal CheeseShop server with very little work.”

That sentence got me a lot of WTF’s and resulted in one of the worst abuses of any system I’ve ever committed.

We had a C# service that would run locally and provide an HTTP REST API for huge amounts of data in our database that was difficult to work with.* However, we had no good way to deploy a C# application, but we needed to get this out to users so people could start building tools against it.
I refused to deploy it by running it out of source control. That is how we used to do stuff and it caused endless problems. I also refused bottlenecks like IT deploying new versions through Software Center.

So in an afternoon, I wrote up a Python package for building the C# app, packaging it into a source distribution, and uploading to our Cheese Shop. The package also had functions for starting the packaged C# executable from the installed distribution. The package then became a requirement like anything else and was added to a requirements.txt file that was installed via pip.

What I initially thought was an unsightly hack ended up being perfect for our needs. In fact it caused us to eliminate a number of excessive future plans we had around distribution. I certainly wouldn’t recommend this “technique” for anything more than early internal distribution, but that’s what we needed and that’s what it did so effectively.

Getting something up and running early was extremely useful. It’s important to walk the line between the “we need to do several weeks of work before you see any result” and “I can hack something together we’re going to regret later,” especially for infrastructure and platform work. If code is well-written, tested, documented, and explained, you shouldn’t have qualms about it going into (internal) production. If the hackiness is hidden from clients, it can be easily removed when the time comes.


* Reworking the data was not an option. Creating this service would have allowed us to eventually rework the data, by providing an abstraction, though.

rob.galanakis@gmail.com

There are 7 comments in this article:

  1. 28/05/2014Stan Seibert says:

    An alternate solution to consider when needing to package non-python software in a mostly Python ecosystem is conda: http://conda.pydata.org/

  2. 28/05/2014Steve Theodore says:

    I take this is some flavor of *nix so you couldn’t just do ClickOnce?

  3. 28/05/2014Rob Galanakis says:

    We could have probably gotten away with ClickOnce since Linux wasn’t on the immediate roadmap. However a) none of us had used it and I didn’t want to spend the time learning it, and b) I wasn’t even sure it fit our requirements, for example some code branches would need different versions of our service. So immediately our use case was already quite advanced.

  4. 28/05/2014cjrh says:

    This scenario is why conda exists.

  5. 28/05/2014Rob Galanakis says:

    While conda seems great, changing deployment or other code to install and use conda is exactly the type of thing I was trying to avoid.

  6. 29/05/2014Alex Clark says:

    I don’t think this “technique” is too unreasonable, especially given that you used your own Cheese Shop.

  7. 1/06/2014RobG3D | Python Tricks says:

    […] provide an HTTP REST API for huge amounts of data in our database that was difficult to work with.* However, we had no good way to deploy a C# application, but we needed to get this out to users so […]

Write a comment:


1 + = nine