Question

wvdpost on Fri, 02 Dec 2011 10:26:24


I have noticed that if you use cspack.exe, the value you set in your csdef file for the physicalDirectory attribute can lead to strange behavior and should NOT contain capital letters if you supply a relative (to the csdef file) path. If you supply an absolute path, the driveletter should be lowercase.
Cspack won't give you an error, but there won't be a sitesroot folder in the generated package!

For example, let's say I have a folder (C:\deploy) that contains a .csdef file and a subfolder that represents my webroot (C:\deploy\WebServer). The subfolder contains a Web.config file and a bin folder with some assemblies. I want this WebServer folder to be my root.

I tried the following combinations for physicalDirectory in the .csdef:
- C:\deploy\WebServer -> No sitesroot folder
- C:\deploy\WebServer\bin -> Sitesroot had bin folder contents (obvious).
- C:\deploy\WebServer\ -> No sitesroot folder
- c:\deploy\WebServer\ -> OK!
- c:\deploy\WebServer -> No sitesroot folder

- WebServer -> No sitesroot folder
- WebServer\ -> No sitesroot folder
- . (only a dot) -> Sitesroot had deploy folder contents
- webserver -> OK!
- webserver\ -> OK!

Notice the difference in upper/lowercase letters and in some cases the influence of the trailing backslash.
In all cases the AppRoot folder inside the package file did contain the correct files (Web.config and bin folder). I reckon this folder uses the path supplied in the /role argument from the commandline (C:\deploy> cspack sd.csdef /role:TestWebRole;WebServer /roleProperties........etc......)

Maybe someone at Microsoft can shed some light on this?


Sponsored



Replies

MingXu-MSFT on Sun, 04 Dec 2011 14:12:56


Hi,

Can you post the csdef file? I'm unable to reproduce this issue with the following definition:
 
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject9" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1" vmsize="Small">
    <Sites>
      <Site name="Web">
        <VirtualApplication name="WebApplication1" physicalDirectory="WebApplication1"/>
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition>

Note I'm using upper case WebApplication1, but the siteroot folder is generated.

 

Best Regards,

Ming Xu.

wvdpost on Mon, 05 Dec 2011 07:38:14


Hi Ming Xu,

This is the csdef file I've used. Note that I am doing all steps manually, I only use Visual Studio to build the solution (which includes a webserver project). After building I copy the Web.Config + bin folder to a separate folder (which already contains the csdef + rolePropertiesFile files) and then run the cspack tool.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="My.Project.Name" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="MyWebserver" vmsize="Small">
    <Sites>
      <Site name="MyWeb" physicalDirectory="webserver">
        <Bindings>
          <Binding name="HttpIn" endpointName="HttpIn" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </Endpoints>
  </WebRole>
</ServiceDefinition>

Thanks!

akarl on Wed, 08 May 2013 14:49:02


This problem is still evident in v2.0 of cspack.exe.  The following powershell works and shows the hackiness that is necessary in order to utilize cspack.  The /sites parameter requires both an absolute path and one where the drive letter is lower case.

$content_path = Resolve-Path .\content
$content_path = $content_path.ToString().ToLower()

& 'cspack' "ServiceDefinition.csdef" "/out:ProjectName.WebRole.cspkg" "/role:ProjectName.Web;content" "/sites:ProjectName.Web;Web;$content_path"

Jeroen (Figlo) on Thu, 09 Jan 2014 17:20:18


I too have experienced the exact same problem. We're using Azure SDK 2.2, and we're using CSPACK to generate the CSPKG. The capitals used in the physicalDirectory attribute in the ServiceDefinition.csdef file, have a big influence on whether the resulting CSPKG file is valid or not. If we specify for example <Site name="Web" physicalDirectory="..\csx\release\roles\ourrolename\approot\"> then we get a perfectly valid CSPKG file, but when specifying <Site name="Web" physicalDirectory="..\csx\Release\roles\OurRoleName\approot"> then the "sitesroot" folder is missing in the package, making it invalid. Note that the CSPACK tool does NOT give an error message, it just results in an invalid package which cannot be used.

Morgma on Wed, 09 Mar 2016 22:22:17


I'm having an issue where my Debug directory, which running from Visual Studio, does not contain the /sitesroot folder, but if I right-click on the cloud service and "Package", I do get a valid .cspkg file including the /sitesroot folder and valid contents (0 and 1 folders representing my two sites within the role).

Have you had a similar experience? Even when updating the physicalPath to any of the recommendations above in the .csdef, I never get a sitesroot folder in /csx/Debug/.. and neither the approot nor sitesroot are used as the physical directories in my local IIS (not Express).

I'm dumbfounded here. My only option seems to manually package and then try to use csrun to actually spin up that package on my localhost.

This thread is awesome, by the way, though it's a bit dated, Microsoft seems to have provided little guidance. I've spent over a week looking for something relevant to my issue and this is the first inkling to come close. The issue lives on now even in Azure SDK 2.8 and Visual Studio 2015.

Jeroen (Figlo) on Thu, 10 Mar 2016 08:15:31


Nope, I did not experience this as you describe it. I did notice back then that Visual Studio actually does create a valid package, it was just CSPACK that was failing. But I did not have problems with the Debug folder, if I remember correctly.