locked
net46 Console App as WebJob -- How Publish?? RRS feed

  • Question

  • User1046475001 posted

    I am new to Azure and WebJobs, and thoroughly confused by the inconsistencies between the online documentation I've found and the current state of tooling. I'm hoping someone here can at least point me in the right direction for more study.

    I have an ASPNET 5/MVC 6 website built on the net46 framework. One element of the solution is a WebJobs project, which is also built on the net46 framework. It works beautifully on my local development machine, and the website works beautifully on Azure.

    Everything is being built inside of Visual Studio 2015, Update 3. All the latest tooling and frameworks are installed.

    But I cannot for the life of me figure out how to deploy the WebJob to Azure. 

    There's supposed to be, from what I've read, a context menu option on the WebJob project that would let me publish it to Azure. There is no such option available. Nor is Azure a publication target when you simply right-click Publish.. The only choice available in the publication wizard is "File System".

    There's also supposed to be a context menu option for the MVC6 website, under Add..., which would allow me to add/couple a WebJob to the website, so that both would be published simultaneously to Azure. There is no such option available.

    The documentation on all of this, being available only online, is either out of date or I haven't found the "right" page yet (that's a problem, Microsoft, with pushing all the documentation to the web -- when things change as rapidly as they are in the ASPNET world these days, there is no way to determine which "documentation" is actually the currently applicable one).

    My working theory about why none of this is working as "simply" as it's supposed to is that the WebJob -- which, again, functions perfectly on my local machine, interacting exactly as it should with Azure Blob Storage and Azure Messaging -- didn't start out life as an "official" WebJob project (i.e., it wasn't initialized from the WebJob template). Instead, I created it as a plain net46 console app. I >>thought<< that would be okay...but I'm beginning to think it's not.

    For fun, I added an "official" WebJob project to my solution. >>It<< displays the Publish to Azure context menu option. I've tried to go through every aspect of its configuration -- it's just a dummy/placeholder right now -- to see what's different from my WebJob, and I haven't found anything different. Except that, of course, it's not built around the project.json concept.

    If it's not possible to do what I'm trying to do -- turn a net46 console app into a publishable Azure WebJob -- I'd appreciate knowing that, so I can switch to plan G (plan B came and went long ago :)).

    - Mark

    Friday, September 23, 2016 2:02 AM

All replies

  • User-646145796 posted

    Hi,

    If you means to deploy Asp.net core console application as webjob to Azure. I think this article could give you helps: https://blog.kloud.com.au/2016/06/08/azure-webjobs-with-dotnet-core-rc2/. Please ensure run.cmd included in publishOptions. Please follow that article. any question, please feel free come back.

    Best Regards,

    Jambor

    Monday, September 26, 2016 7:26 AM
  • User1046475001 posted

    Thanx, Jambor. I had come across that article in my research, and it >>almost<< got me to the finish line.

    Unfortunately, I ran into the infamous UTF-8 BOM (byte order marker) bug.

    When Visual Studio creates a text file, like a cmd or bat file, when it saves it, by default, it saves it using UTF-8 encoding (at least, that's the default in the US; I imagine there are different defaults for different countries).

    In saving it as a UTF-8 file, it inserts several bytes (three, I think) at the very beginning of the file, which define, I guess, the UTF-8 byte order. You never see those bytes when you open the file in Visual Studio, so you have no reason to suspect they're there.

    However, the Azure command processor apparently expects an absolutely pristine character-only file. When it encounters the BOM, it throws up, complaining that that line in the file is incomprehensible. It prints out an error message to that effect, which includes a text representation of the BOM...but the characters just look like noise, and are easily ignored.

    In my case, the only line in the cmd file was this:

    UploadProcessor.exe

    which should've launched that executable.

    Needless to say, when I saw that silly error message I assumed the problem had something to do with what >>I<< had done, so I went into an in-depth analysis of the code that generates UploadProcessor.exe. But since the problem wasn't in what I'd done, I just ended up wasting hours of time.

    The solution, while easy, is not intuitive: when you first save the run.cmd or run.bat file in VS, do a Save As rather than a plain Save. Work your way through the options for how to save the file, and select (in my case) "UTF-8 without BOM". That saves a pristine file, and, so long as you don't delete and recreate it, VS will remember you want the file saved without the BOM, and you can do plain old Saves from that point on.

    I've written a blog post about this at http://imperfect.olbert.com/2016/09/23/azure-webjobs-hidden-utf-8-parameters-and-azure/.

    Since I hope there are Microsoft engineers monitoring this forum, let me close with this: it is absolutely nuts that one Microsoft product saves a file that another Microsoft product is designed to use...but throws up on.

    Please re-write the Azure command file processor so that it either is "BOM aware" or, if that's too hard, that it ignores the BOM.

    I suspect this kind of glitch is due to Microsoft's mad rush to integrate itself with the open source world after decades of trying to supplant it. But one of the key hallmarks of the Microsoft development experience is that "our stuff works together (reasonably well)". When that gets violated, the value proposition for using Microsoft stuff drops. A lot.

    - Mark

    Monday, September 26, 2016 3:52 PM