What is the name of the web role .config file with SDK 2.2 - azure

I have a web role in which I have extended the RoleEntryPoint to do some work that is outside of the scope of the web site. As part of the RoleEntryPoint.Run() my code is required to read from the .config using ConfigurationManager.
While this is a little unusual, using SDK 1.8 I was able to make this work by ensuring that my package included a [The name of my project].dll.config file.
Now that I have upgraded to SDK 2.2 when I try to use .AppSettings or .GetSection() the values are always null, which leads me to believe it is unable to find my file.
I have tried deploying a Worker Role and the .config file still follows the same name pattern that I'm currently using.
I have also tried naming the file WaIISHost.exe.config.
I am aware that ideally this configuration should be included in the .csfg file, but my questions is does anyone know what I should be calling my config file?
UPDATE:
With the help of this question, I now know that the name of the config file it is reading from is E:\base\x64\WaIISHost.exe.Config, but I don't know why this has changed or what I can to overide this.

After much investigation and trial an error I finally have a solution.
The name of the file is still required to be [The name of my project].dll.config, but you need to make sure that this file is in your approot\bin\ directory of your package.
I believe my initial problem was caused by the Copy to Output Directory property being changed to Do Not Copy, although I'm unsure how this happened. If you find yourself in a similar situation you can just add a file with the correct name to your project and set the Copy to Output Directory to be Copy Always.
Once I'd done that however I realised I had another problem. I needed the .config file to have had the config transformations run over it, which this didn't do. To fix this I updated the .ccproj file to have the following:
<PropertyGroup>
<!-- The first two of these targets are what is defined in the base SDK 2.2 targets file. When we upgrade we may need to look reassess this. -->
<CopyRoleFilesDependsOn>
CopyWebRoleFiles;
CopyWorkerRoleFiles;
CopyWebConfigToBin;
</CopyRoleFilesDependsOn>
</PropertyGroup>
<Target Name="CopyWebConfigToBin">
<!-- We need to copy the transformed Web.config to the bin directory so that the RoleEntryPoint has access to the config settings.-->
<Message Text="Copy %(WebRoleReferences.OutputDir)Web.config tp %(WebRoleReferences.OutputDir)\bin\BackOffice.UI.dll.config" Importance="high" />
<Copy SourceFiles="%(WebRoleReferences.OutputDir)Web.config" DestinationFiles="%(WebRoleReferences.OutputDir)bin\[Name of project].dll.config" />
</Target>
This adds an extra target which waits until all of the other files have been copied to the appropriate directory and then picks up the web.config and puts a copy in the bin directory with the correct name.

Are you able to put the config values into the Azure config file (the .cscfg) rather than using the .config file? You can read the values from the cscfg via the RoleEnvironment.GetConfigurationSettingValue static method.

This page explained why it's called WaIISHost.exe.Config and where you can put it in your project.
http://azure.microsoft.com/blog/2010/12/02/new-full-iis-capabilities-differences-from-hosted-web-core/
Like knightpfhor mentioned, you can also use [AssemblyName].dll.config to put these configuration too. It depends on the assembly name of your project, you can check property of your web role project.

Related

Can I disable shadow copy in an Azure function?

We are working on a new feature that uses third-party plugins that are stored in a directory named 'Plugins'. One particular plugin expects certain files such as the license file to be in the same directory as the plugin assembly (DLL) based on the assembly's Location value. However, due to shadow copy the license file is in the folder where it was originally deployed and the assembly Location value is the 'Temporary ASP.NET Files' subfolder after shadow copy. Is there any way to disable shadow copy to work around this issue?
I suggested to the plugin provider to use CodeBase rather than Location. They are considering it, but I have to complete this feature now so I can't wait for that code change.
My current desire is to disable shadow copy so the Location property value of the assembly is the location where all the plugin files are initially deployed to.
Cause Azure Function doesn't support web.config, have to find other ways to implement it.
In github there is one way to solve it, and in this comment it says no shadowcopy in v2, maybe you could have a try. Add this directive in your Web Deploy pubxml for your publish profile:
<EnableMsDeployAppOffline>True</EnableMsDeployAppOffline>

Include referenced assembly's configuration in cspkg

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.

VS2012 pubxml and TransformWebConfigEnabled

Maybe someone can advise me.
I am trying to publish a project using VS2012. I have setup a publish profile to publish it to a file system drive.
I have several environments/build configurations required and thusly am using Web.Config transformations.
At the moment, I have a web.config + 5 transforms (one for each build config). When the solution is published, it successfully deploys to the file system specified. However it also transforms the Web.Config into web.config.
I have modified the .pubxml to include the <TransformWebConfigEnabled>False</TransformWebConfigEnabled> element, but the publish process just seems to ignore it and transform the web.config regardless.
Followed via this link: http://msdn.microsoft.com/en-us/library/dd465342(v=vs.100).aspx
Can anyone advise?
[edit]
I have tried putting <TransformWebConfigEnabled>False</TransformWebConfigEnabled> element into both the pubxml and the proj file and both ways it get's completely ignored and the web.config is transformed regardless.
You are sticking it in the wrong file. You want to modify
YourProject.csproj
instead of PublishProfile.pubxml.

Logging via FileAppender

here is an easy question coming:
i am trying to use log4net to log the infos on a file. i wrote
< file value="log-file.txt" /> into my appender tag in app.config. and now wondering where the log-file.txt is positioned and whether it is created automatically or i should create it by myself.
i am using c# - wpf
It should be in the Debug\Bin or Release\Bin folder.
if its not there, try specifying full path.
The file will automatically be created if it doesn't exist.
It may require that the application has write permission to the folder where the logfile is placed.
As Orentet mentions this is normally the bin folder.

Configuring CruiseControl.net project directory

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

Resources