3

I'm trying to build an Azure deployment package using cspack on my build server for devfabric deployment (csrun) onto a test server. cspack dutifully copies the web role binaries & files into the csx package, but it also requires a 'sitePhysicalDirectory' path for each web role, which is embedded in a 'RoleModel.xml' file. This directory must exist at package time.

Upon deployment, csrun sets up an IIS site that points directly to the sitePhysicalDirectory path and appears to completely ignore the web role binaries packaged in the csx package. Needless to say, the test deployment on a different machine doesn't work.

Am I missing something here? Why can't cspack/csrun set the physical path in IIS to the approot in csx package? What's the purpose of a csx package if the packaged binaries are not used? What does sitePhysicalDirectories do in a production Azure deployment?

Community
  • 1
  • 1
Sam
  • 4,694
  • 2
  • 36
  • 47
  • I too came across this same situation and edited the physical directory in csx file for webrole in test server but the worker role still doesn't work and still points to worker role path in dev machine. – Manish Mar 06 '12 at 02:23
  • I was having similar difficulties and eventually gave up on CSPack and used msbuild instead. See here: http://stackoverflow.com/questions/18117994/cspack-behaviour-differs-from-msbuild – acarlon Aug 13 '13 at 01:37

3 Answers3

6

I'm beginning to think the answer to all of those questions is "Because cspack/csrun are poorly-designed piles of garbage that should never have shipped". They seem to be built for Visual Studio support and nothing else.

Manually updating the RoleModel.xml file to set the physicalPath attribute to 'approot' (it's relative to the RoleModel.xml location) after packaging appears to be a viable workaround.

Sam
  • 4,694
  • 2
  • 36
  • 47
  • Sam, how did you actually solve this problem? We are doing this right now and running into exactly the same problems. I REALLY don't want to do some sort of remote execution of cspack/csrun on our internal test servers that host the emulator, but that's the only idea I have at this point. – Jaxidian Aug 26 '11 at 20:43
  • I managed to get cspack working with a bunch of manual hacks, but I never had any luck with csrun. I tried both psexec & powershell remoting to the test server and both had problems. I came to the conclusion csrun is really only designed for the dev workstation and attempting to do what I was doing was fighting the tools. We ended up just using msdeploy to a vanilla web application using a separate package - this may or may not be suitable for your situation. – Sam Aug 27 '11 at 07:32
  • Sadly, I am coming to the same conclusion. All made worse by the documentation that seems to skimp when it comes to the meat. – acarlon Aug 08 '13 at 04:29
2

I think part of this has to do with the addition of Full IIS. It used to be the case that your approot directory in Windows Azure was for both the RoleEntryPoint process and the IIS WAS Host (one in the same). However, with full IIS, you would have w3wp.exe running your web code and the WaWorker process executing your RoleEntryPoint.

The decision was made to effectively copy the entire website (which also has the WebRole.cs RoleEntryPoint) to a new directory and root full IIS there. As such, you will notice that your packaging for Web Roles actually contains a copy of your code twice. Once, for the website and once for the WebRole.cs RoleEntryPoint. Only your RoleEntryPoint is executed now out of approot. I don't remember all the technical reasons why this occurred, but it might have been easier/safer to copy the website out rather than risk missing a dependency.

dunnry
  • 6,858
  • 1
  • 20
  • 20
  • Thanks, that helps clarify a bit. It was certainly done for Full IIS, but the csx package does NOT appear to have two copies of the code - it has one copy of the code, and one reference to code on the filesystem outside the package. This is fine for F5 in Visual Studio, but building on a build server and deploying on a test server can't be done without fiddling with the package internals. It makes one wonder if the Azure engineers understand what's commonly meant by the term 'package'. – Sam May 19 '11 at 01:41
  • I'll mark you as the answer as I've realised it's not a particularly good question. Note to self: never post while angry at crappy framework code. – Sam May 19 '11 at 06:22
  • Yeah! Pity answer... :) I will have to re-check the package structure. My answer was correct in the 1.3 release, I suppose they might have fixed the double copy in the 1.4 updates. – dunnry May 19 '11 at 17:51
1

I would think that sitePhysicalDirectory should be set as the folder under AppRoot in your csx package, not the source of your web role binaries & files.

axel22
  • 32,045
  • 9
  • 125
  • 137
Jackie
  • 11
  • 1