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.
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>
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.
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?
Related
I have an executable that I want to be deployed together with my Azure web role. The executable has a configuration file that needs to be included as well.
I tried adding a reference to the executable's project in my web role project, which made the exe file appear in the bin folder of the cspkg, but not the configuration file.
How can I get the configuration file to be included as well?
It seems wrong to include it directly as a content file in the web role project because this file is a build artifact (app.config gets renamed to .config.exe during build).
Thanks!
In an early SDK they added the concept of Role Content folders, or folders you could point to in the service definition file and say anything in this folder, add it to the package and deploy it with the role. If you look at the schema for the Service Definition you'll see these listed on the both the web and worker roles schemas. You can manually add this and point to any location on the local system and anything in that directory will be picked up and included.
<WebRole name="SimpleWeb" vmsize="Small">
...
<Contents>
<Content destination="ConsoleApp">
<SourceDirectory path="c:\src\SimpleWebContent\ConsoleApp\BuildOutput" />
</Content>
</Contents>
</WebRole>
For example, you could point to the output directory of the build for your executable so that anything that is generated by your build for that executable would be included. You can set the destination directory in relation to the app root, but the tricky part is the source directory. Note in my example above the full path is provided. The documentation says that you can use a relative path, but I tried many combinations and the behavior seemed very quirky. The complete path does work.
The VS SDK tools didn't expose this until SDK 1.7 and it's still not very good. Phil Hoff did a blog post on it called "Add Files to your Windows Azure Package using Role Content Folders". Note that when you use this method of adding the files you won't see the content elements appear in your service definition. They get auto injected at package time. If you are doing this as part of a build process that may not happen since VS tooling is doing the injection, but to be fair I didn't try calling cspack directly to see if having the content elements included in the service definition file actually packaged those or not. Also, I found that just adding a new folder and just having files under that folder didn't seem to work. I had to actually add the files by name there, which seemed wrong. I did hack the .ccproj file to use a wildcard on the folder include, which did work, but also seemed like a hack to me.
I am using Microsoft's AjaxMin to minify javascript on my website, which is hosted by Azure. I am using a BuildTask to automatically minify javascript at run time. This build task is specified in the .csproj file.
The process is working on my local environment, however, it does not work when I deploy to my Azure site. The azure site throws 404: file not found errors, when i try to reference the minified version of .js files.
Is it possible to use build tasks on an Azure site? Is there anything I am missing? I have made sure not to include the .min.js files in source control as this (http://www.asp.net/ajaxlibrary/AjaxMinQuickStart.ashx) tutorial suggests, but I am wondering if there is anything specific to Azure that I need to set up.
Thanks!
I've got this working properly in my projects. I'll tell you how I did it, though this may not be the simplest or most straightforward way.
Before we get started, it's helpful to be able to check if your minified files are included in the Azure deployment package without actually deploying. It's pretty easy to do. The .cspkg file is actually a zip-formatted file, so you can open it with any zip archiver. (I like to use 7Zip for this because the right-click -> Open Archive command doesn't require you to rename the file, but you could use Windows Explorer, WinRAR, etc.) Inside the .cspkg you'll see another large file with a .cssx extension. That's a zip file too. Inside of the .cssx you'll find a sitesroot folder with a subdirectory for each website you're deploying, which will contain all your actual website files. So you can poke around in there and see what files are being deployed to Azure.
First, try editing the project file for your web project (the one that contains all the Javascript/CSS files). You can use Notepad, or in Visual Studio right-click the project, select "Unload Project", then right-click again and select "Edit ". Inside the project file, insert a section like this:
<ItemGroup>
<!-- Copy over all the minified CSS & JS to the output directory-->
<Content Include="**\*.min.css" />
<Content Include="**\*.min.js" />
</ItemGroup>
Then reload the project, repackage it, and see if your files are included in the .cspkg file. If they are, then you're done.
If not, there are a couple other things to check. Your minification might not be running at the right build stage. My minification target looks like this:
<Target Name="PrepWebApp" Condition="$(Configuration)=='Release'" AfterTargets="AfterBuild">
If that's still not working and your Web Role has multiple Sites and/or Virtual Applications in it, it's possible that the packaging steps are not running for all of the sites. So when you go to package your project for deployment to Azure, it may still not be running the minification step (along with the web.config transformations, and some other things). If that's the case, see this blog post for a way to fix it.
Just in case that blog post goes away, I'll copy the most relevant bit here. You would put this in the .ccproj file for your web role (with appropriate bits changed to match your project structure):
<PropertyGroup>
<!-- Inject the publication of "secondary" sites into the Windows Azure build/project packaging process. -->
<CoreBuildDependsOn>
CleanSecondarySites;
PublishSecondarySites;
$(CoreBuildDependsOn)
</CoreBuildDependsOn>
<!-- This is the directory within the web application project directory to which the project will be "published" for later packaging by the Azure project. -->
<SecondarySitePublishDir>azure.publish\</SecondarySitePublishDir>
</PropertyGroup>
<!-- These SecondarySite items represent the collection of sites (other than the web application associated with the role) that need special packaging. -->
<ItemGroup>
<SecondarySite Include="..\WebApplication1\WebApplication1.csproj" />
<SecondarySite Include="..\WebApplication2\WebApplication2.csproj" />
</ItemGroup>
<Target Name="CleanSecondarySites">
<RemoveDir Directories="%(SecondarySite.RootDir)%(Directory)$(SecondarySitePublishDir)" />
</Target>
<Target Name="PublishSecondarySites" Condition="'$(PackageForComputeEmulator)' == 'true'
Or '$(IsExecutingPublishTarget)' == 'true' ">
<!--
Execute the Build (and more importantly the _WPPCopyWebApplication) target to "publish" each secondary web application project.
Note the setting of the WebProjectOutputDir property; this is where the project will be published to be later picked up by CSPack.
-->
<MSBuild Projects="%(SecondarySite.Identity)" Targets="Build;_WPPCopyWebApplication" Properties="Configuration=$(Configuration);Platform=$(Platform);WebProjectOutputDir=$(SecondarySitePublishDir)" />
The build task will run in Visual Studio when you build the project. You need to make sure that the minified files are also being deployed to Azure.
I'm guessing that perhaps because the item is being generated at build-time that it's not part of the project itself, and is this ignored by the deployment step.
Please check that the deployment system being used will include all the script files and not just the ones that are in the project itself.
I'm developing an app. using Common.Logging (http://netcommon.sourceforge.net/index.html).
A simplified logging configuration (which is done in web.config) is as follows:
<configuration>
...
<arg key="configType" value="FILE" />
<arg key="configFile" value="NLog.config" />
...
</configuration>
As you can see here, the configuration points another configuration file (here, NLog.config) of a backend logging framework.
My question is: when deploying in Azure, what path should I specify here (on dev, NLog.config is copied when building the solution, and placed in the bin directory). In other words, what would be the SAFEST way to get the physical place where the app is deployed in Azure?
Thanks in advance!
In code you can find the current path to the application using Server.MapPath("/"). Now, you can simply make sure that the NLog.config file gets deployed to the application folder:
Add NLog.config to your project (in the root of your web application)
Change the Build Action to Content
In order to test this you can right click on your Azure project an choose Package. In the bin\Release|Debug\app.publish folder of your Azure project you'll find a *.cspkg file. Add a .zip extension to this file and open the file with WinRAR/ZIP/7zip/... Then you'll see a file like this one: SomeWebRole_1a91f39a-49b7-4ece-873f-862172a2fa06.cssx. Here again, add the .zip extension to this file and open it.
If you navigate to the sitesroot\0 folder you'll see the files of the web application in IIS, including the NLog.config file. This way, you' can simply reference the NLog.config file in the Common.Logging settings:
CruiseControl.net creates (by default) for each project a subdirectory under: c:\Program File\CruiseControl.NET\server
How can I change that? (it's such a bad idea to mix data with program files...)
I found a way to configure the artifacts directory per project, but that's not quite it (it's merely a subdirectory of the project directory).
Set the project's working and artifact directory and you're done. They default to:
[ccnet-install-dir]\[project-name]\WorkingDirectory
[ccnet-install-dir]\[project-name]\Artifacts.
If you e.g. set these directories to...
[projects-dir]\[project-name]\WorkingDirectory
[projects-dir]\[project-name]\Artifacts
... you can safely remove the [ccnet-install-dir]\[project-name] subtree (You will loose your project build history then).
So your configuration will look like this:
<project name="foo">
[...]
<workingDirectory>C:\projects\foo\WorkingDirectory</workingDirectory>
<artifactDirectory>C:\projects\foo\Artifacts</artifactDirectory>
[...]
</project>
I have CC.NEt not installed here, and I have atm no access to my build-server at work, but if I remember well, you should find 2 configuration files in your c:\Program Files\CruiseControl.NET folder.
ccnet.exe.config and ccservice.exe.config.
The first configuration file is used when you run CC.NET using the console app, the second one is used when you start CC.NET as a service.
In those files, you should find a configuration-setting which points to the location where the configuration-file(s) that describe the build-process for your projects can be found.
edit:
In the ccservice.exe.config file, you'll find a key in the appSettings section which is called ccnet.config. Change the value of this key to the path where you want to put the ccnet.config file.
If this key is not present, you can add it:
<appSettings>
<!-- Without this appSetting ccservice will look for ccnet.config in its own directory. -->
<add key="ccnet.config" value="D:\CCNetConfigFiles\ccnet.config"/>
</appSettings>
This is how I've done it:
I've changed the ccnet.config appSetting in the ccservice.exe.config file, so that CruiseControl.NET searches for the ccnet.config file in a different location instead of the standard location. (As described above). (I understand that you do not want to do this ?)
I've changed the ccnet.config file itself, so that it looks like this:
<!DOCTYPE cruisecontrol [
<!ENTITY project1 SYSTEM "file:D:\CCNETConfigFiles\project1\project1buildconfig.xml.config">
<!ENTITY project2 SYSTEM "file:D:\CCNETConfigFiles\project2\project2buildconfig.xml.config">
<!ENTITY project3 SYSTEM "file:D:\CCNETConfigFiles\project3\project3buildconfig.xml.config">
]>
<cruisecontrol>
&project1;
&project2;
&project3;
</cruisecontrol>
By doing this, I can have each project configuration in its own file, and I can put each project-configuration in its own directory.
Then, I just have to make sure that in each project config-file, I remove the cruisecontrol tags, because otherwise the ccnet.config file wouldn't validate against the schema.
Probably not the answer you're waiting for, but could still be interesting: we're using about twenty build machines with about fifty different builds. Because indeed it's not a good idea to mix data with program files, we decided to put our ccnet installation in source control. Each server has its own configuration file in that directory (also in source control) and a local batch file or short cut starting ccnet specifies which configuration file is used. This means that local data (the build logs) are mixed with data that is in perforce (ccnet binaries/configuration files), but we have accepted that situation. Hope this helps.
Regards,
Sebastiaan
Now i am using the sharepoint extensions 1.2 for Visual Studio 2005 to deploy my website. I want to add an assembly to the bin, but i don't know how to add it to the Team Definition.
Could someone give some code, plz?
OK I found a solution.
First you have to add the assembly you want to deploy into the VS project. For example you can create a "libs" folder to store all external assemblies you'll need in your team site.
Then you have to edit the manifest.xml file of your Team Site Definition. You can find this file within the "pkg" folder within your project. Be aware that the pkg folder will only be available if you've at least deployed the solution one time.
OK, now you have to add a new <Assembly> child element to the <Assemblies> element within the manifest.xml file of your Team Definition solution. With the "DeploymentTarget" Attribute you can define whether the assembly should be deployed to the GAC or to the web application's bin folder.
The following example shows how the <Assemblies> element looks like if you want to add the "TeamSiteDefinition1.dll" to the GAC and to add the "TestSolution.dll" to the bin folder. If you need a safe control entry for your assembly you can add this one too.
<Assemblies>
<Assembly Location="TeamSiteDefinition1.dll" DeploymentTarget="GlobalAssemblyCache" />
<Assembly Location="TestSolution.dll" DeploymentTarget="WebApplication">
<SafeControls>
<SafeControl ..... />
</SafeControls>
</Assembly>
</Assemblies>
If there's any SharePoint-relevant code (web part, event receiver etc) in your project, the assembly will be packaged up in the resulting WSP and your solution manifest will already have an instruction to put it into the GAC. Any particular reason you need it in the bin rather than the GAC? It can be done -- read up the documentation on the Solution Manifest XML format -- but requires manipulating the solution manifest from WSP View manually, and might require re-creating the WSP with WspBuilder.