CODEWITHSUNDEEP
azureazure-web-roles
MLowijs
MLowijs

Reputation: 1495

Azure sitesroot does not contain all deployed files

I'm deploying a web role to Azure using VS 2013. I added a Contents element to my .csdef file to deploy extra files that are not included in the Azure deployment package like this:

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="..." xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
  <WebRole name="..." vmsize="Small">
    <!-- snip -->

    <Contents>
      <Content destination="bin/">
        <SourceDirectory path="C:\...\bin"/>
      </Content>
    </Contents>
  </WebRole>
</ServiceDefinition>

When the package is deployed, I can see the extra files being put in the approot folder on the instance's F: drive. However, these files are never deployed to the sitesroot\0 folder, from which the web role seems to run. Because these extra files are assemblies that are to be loaded dynamically, I would like them to be together with the application's other assemblies.

Is this behavior intentional or am I doing something wrong? There doesn't seem to be much information about this online.

Upvotes: 0

Views: 1222

Answers (3)

MLowijs
MLowijs

Reputation: 1495

I ended up using the Content element in the end, but with a different destination path, pointing to the sitesroot folder. It's a bit of a hack, but at least it works without diving into MSBuild or manual packaging of the deployment.

<ServiceDefinition name="..." xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
  <WebRole name="..." vmsize="Small">
    <!-- snip -->

    <Contents>
      <Content destination="..\sitesroot\0\bin">
        <SourceDirectory path="C:\...\bin" />
      </Content>
    </Contents>
  </WebRole>
</ServiceDefinition>

Upvotes: 1

Jaxidian
Jaxidian

Reputation: 13511

You can add a DLL to your root directory of a project (Add -> Existing Item). If you take that DLL and change the Build Action set to Content and the Copy to Output Directory set to Copy Always then I think this will make sure that the DLL ends up being in your BIN folder, or equiv.

An example of what I've done in the past: Two projects in a Solution named:

  • DependenciesProject (Class Library)
  • WebProject (MVC App)

I had a need where some specific DLLs that needed to be bundled into the compiled package were included but the specific DLL that would be used would change based on my compiled targets (x64 vs x86). The solution we chose to go with was to have the DependenciesProject do what I described for you to do above and we modified the .csproj file to change the path to these native DLLs based on the target specified at compile-time (we disabled Any CPU).

So the DependenciesProject had these DLLs in the root directory (with that .csproj having some tweaks for dynamic paths to the DLLs that existed in our Nuget packages folder) and the DLLs in the Solution Explorer had the Build Action set to Content and the Copy to Output Directory set to Copy Always. This means whenever a DependenciesProject.dll file was compiled, it would move the other DLLs into the same output folder as that .DLL file.

Now WebProject project would have a Project Reference to DependenciesProject. This means every time I try to compile WebProject, it will first compile DependenciesProject and then copy its output folder into the WebProject's output folder.

The end result: DependenciesProject.dll as well as MySpecial.dll existed with my web application every time I needed it.

Does this help?

Upvotes: 0

Simon W
Simon W

Reputation: 5496

The behaviour is as per the documentation which states that the deployed location is relative to the Role's APPROOT (the behaviour you are seeing).

If you want them deployed into your site's bin folder you need to package them as part of your Visual Studio solution.

Upvotes: 0

Related Questions