After reading that I shouldn't set the context in server.xml, I tried creating META-INF/context.xml. The Resource definitions are read ok but the path attribute is ignored.
<Context path="/webapps/uebersetzung" docBase="UebersetzungWeb">
<Resource ....
</Context>
The war file is UebersetzungWeb and I want to set the context path to webapps/uebersetzung. (I am migrating a WebSphere app and the context path is hard-coded in many places)
So far, the only way I found to do this is to rename the war to webapps#uebersetzung before deployment.
Is this the correct way?
Related
I want to package a folder with msdeploy.exe to a zip destination at the end of CI process.
I run the following command line
msdeploy.exe -verb:sync -source:contentpath="C:\SampleWebApp" -dest:package="c:\SampleWebApp.zip" -declareParamFile="parameters.xml"
I also like the *.deploy.cmd and *.SetParameters.xml which msbuild generates when it spits out a deployment package. I renamed the one set of *.deploy.cmd and *.SetParameters.xml file and changed the content accordingly. to be able to run in deployment environment.
When I run *.deploy.cmd file it generates the folder "C:\SampleWebApp" rather than creating the iis app based on parameters provided in .SetParameter.xml.
After some investigation, I've found that the .cmd deploys to -dest:auto which is good. but apparently my package manifest inside the package indicates that this package is contentPath whereas packages generated by msbuild has more complex manifest in archive.xml inside package using iisApp provider.
Having looked at following post
http://blogs.msdn.com/b/webdev/archive/2013/01/09/real-scenario-folder-deployment-scenarios-with-msdeploy.aspx
I believe if I use -source:manifest="Package.xml" with right Package.xml the end result should be similar to VS package output
The I thought maybe the *.SourceManifest.xml is the manifest for the package. I used and it builds the package but when I want to deploy that to the using .deploy.cmd it complains about setAclUser
Error: A value for the 'setAclUser' setting must be specified when the
'setAcl' provider is used with a physical path.
Does anybody know that is the manifest msbuild uses?
To directly answer your question: the manifest is generated dynamically based on MsDeploySourceManifest MSBuild items.
You can make it use contentPath rather than iisApp by declaring DeployAsIisApp=false in your publish profile (or command line /p:DeployAsIisApp=false). This will also disable the setAcl providers.
If you want to keep iisApp, you can disable the ACL providers...
... being added to the package by declaring IncludeSetAclProviderOnDestination=false in your publish profile
... being deployed by passing /I:False to deploy.cmd
Following is the manifest template
<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
<iisApp path="[PATH1]"/>
</sitemanifest>
and Parameter.xml template
<parameters>
<parameter name="IIS Web Application Name" defaultValue="WEBSITENAME" tags="IisApp">
<parameterEntry kind="ProviderPath" scope="IisApp" match="^[PATH1ESCAPED]$" />
</parameter>
<!-- appSetting section-->
</parameters>
note: [PATH1] should be replaced with your folder path like C:\MY.FOLDER\WWW
and [PATH1ESCAPED] should be same path but escaped with postfix and prefix ^ $ like
^C:\MY.FOLDER\WWW$
Then you can call
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:manifest="Manifest.xml" -dest:package=%1 -declareParamFile="parameters.xml"
and %1 being folder path like C:\MY.FOLDER\WWW
We are upgrading to solr 4.4 and would like to be able to use the new core.properties for the new core discovery.
Currently, we have a couple of properties defined in the solr.xml for most of the cores, and I am not able to create these same properties in the new core.properties file.
Here is a core as currently defined in solr.xml:
<core name="core1003" instanceDir="core1003">
<property name="xmlDataDir" value="D:\Solrfiles\ImportFiles\core1003.xml" />
</core>
This is then used in DIH-XPathEntityProcessor.xml with <str name="xmlDataDir">${xmlDataDir}</str>.
How can I define core specific property variables like this? It doesn't necessarily have to be in core.properties, but that would make it a little easier to manage.
In your core instance directories that contain your core.properties file create a conf/ subdirectory and a solrcore.properties file in it. Define your core specific properties there and it will be picked up automatically.
Alternatively, you can add a value for "properties" to your core.properties file to point to any other file:
properties=/your/path/here.properties
I believe but have not confirmed that for this to work your cores must load on startup and must not be transient. Any non-standard properties you add to core.properties will be ignored because the CoreDescriptor copy constructor only persists the following properties from that file in memory: instanceDir, config, schema, name and dataDir (see CoreDescriptor:91 in the 4.4.0 source). I believe this is a bug?
Is there a way to factor out and parameterize repeating parts of Logback XML configuration? I have many different rolling file appenders configured basically the same except for the file names. I use that in conjunction with a bunch of loggers with their 'additivity' turned off so I can redirect different parts of the stack to different files. This adds up to a cumbersome and long configuration file composed of many almost identical segments.
I've used Logback's <include> feature before, but it doesn't address this reuse issue since I can't parameterize the included configuration. I'd expect such a feature to look something akin to:
<include resource="file-appender.xml">
<property name="filePath" value="/where/logs/go" />
<property name="baseLogger" value="com.mycompany.thatpartofthestack" />
</include>
But as far as I understand that's wishful thinking. Is there another way of factoring out Logback's configuration via templates, macros, functions or whatnot?
Try using variable substitution in local and/or context scope.
Perhaps the easiest way is to define variables in some resource file, say logback.properties bundled with each each application. Moreover, each application would carry a logback.xml file importing logback.properties.
<configuration debug="true">
<property resource="logback.properties" />
<!-- set root level as given by the value of the root.level variable -->
<!-- if root.level is undefined default to DEBUG -->
<root level="${root.level:-DEBUG}"/>
</configuration>
If you wish to set the root level to WARN in webapp-A, simply add the following line in logback.properties file bundled with webapp-A.
root.level=WARN
You can bundle logback.xml as a resource in a artifact common to your various applications.
We are using Nlog as logging tool with our Worker Role of Azure app.
It requires NLog.config file. We installed "SlowCheetah - XML Transforms", and have two Debug/Release transforms).
Solution does get rebuild successfully.
But when I try to run, I am getting following error. (I used exact transformation for nolog.config in one of my Windows service app, and it is working fine there).
Error 163 The item "bin\Debug\NLog.config" in item list "OutputGroups"
does not define a value for metadata "TargetPath". In order to use
this metadata, either qualify it by specifying
%(OutputGroups.TargetPath), or ensure that all items in this list
define a value for this metadata. C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure
Tools\1.6\Microsoft.WindowsAzure.targets 2299 5 Insight.CloudWeb
I don't know if this is done by the SlowCheetah extension, but could you verify if your *.csproj file contains the AfterCompile target similar to this?
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<UsingTask TaskName="TransformXml"
AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterCompile" Condition="exists(’app.$(Configuration).config’)">
<TransformXml Source="NLog.config"
Destination="$(IntermediateOutputPath)$(TargetFileName).config"
Transform="NLog.$(Configuration).config" />
<ItemGroup>
<AppConfigWithTargetPath Remove="NLog.config"/>
<AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
<TargetPath>$(TargetFileName).config</TargetPath>
</AppConfigWithTargetPath>
</ItemGroup>
</Target>
Take a look at Oleg's blog post .Config File Transformation under App.config File Transformation for more information.
I have a fix for this. Now you should be able to transform app.config as well as other XML files for Azure Worker Roles using SlowCheetah. Once I get the fix verified I will release the update to the VS gallery.
If you would like to try the fix you can download the updated VSIX at https://dl.dropbox.com/u/40134810/SlowCheetah/issue-44/SlowCheetah-issue-44.zip. If you are interested in following up on this please use the issue #44.
So, appSettings can be set in app.config, web.config, machine,config... But, when you work under IIS 7 you can also have appSettings being applied under applicationHost.config with a specific carve out for your site. So, what's a consistent way for me to know what AppSettings I should be using???
System.Configuration.ConfigurationManager is fine if this is a client profile.
System.Web.Configuration.WebConfigurationManager if this is a web-app ... well, maybe.
Microsoft.Web.Administration if I expect values in applicationHosting.config - ouch ... and even then they don't roll-up hierarchically so it seems that you're left holding that process.
Does anyone have a consistent approach to processing AppSettings that accounts for applicationHost.config?
You can't actually specify <appSettings> in your applicationHost.config file. This is because applicationHost.config defines settings specific to IIS only. You can review the applicationHost.config schema to confirm this:
%systemroot%\System32\inetsrv\config\schema\IIS_schema.xml
If you try to edit applicationHost.config and add an <appSetting> section to a site or under a <location path="..."> section you will get an error (IIS may not start and IIS MMC console will display a configuration error).
If you configure a global application setting in IIS manager this actually gets configured in the master web.config file that matches the default .NET Framework version setting in IIS.
<appSettings/> is specific to the .NET Framework and can only be configured in:
%SYSTEMROOT%\Microsoft.NET\Framework\[framework version]\CONFIG\machine.config
%SYSTEMROOT%\Microsoft.NET\Framework\[framework version]\CONFIG\web.config
%SYSTEMROOT%\Microsoft.NET\Framework64\[framework version]\CONFIG\machine.config
%SYSTEMROOT%\Microsoft.NET\Framework64\[framework version]\CONFIG\web.config
and of course your application's app.config or web.config files.
My advice would be to keep these settings local to your application unless there is the rare occasion where you need some value to be available globally.
Update:
Now that I understand your problem - you have multiple IIS sites which all point to the same physical folder - there is a way to approach this.
You could have a configuration table in your database that has a primary key of whatever the HTTP_HOST value is. This maps to a prefix, for example:
Host SitePrefix
==== ======
domain1.com D001
domain2.com D002
In your web.config:
In your application's Application_Start event in Global.asax.cs initialise an application wide value:
void Application_Start(object sender, EventArgs e)
{
// Code that runs on application startup
string httpHost = HttpContext.Current.Request.ServerVariables["HTTP_HOST"];
Application["SitePrefix"] = GetSiteKeyFromDb(httpHost);
}
This value will be available across the whole application but unique to the site.
When you need to read a setting that is specific to the site:
string siteSetting = ConfigurationManager.AppSettings[
HttpContext.Current.Application["SitePrefix"] + "_Setting1"
];
But if you're hitting the database in Application_Start then it may actually be expedient to store all these site specific settings in the database then read and cache them in Application instead of using <appSettings />.
I used the information provided by Anti-Santa's answer to accomplish this but I didn't want to parse the URL and have another database to look up information. The same codebase is used on-premise and I wouldn't have those pieces in that scenario.
Just add the appSettings to the .NET Framework web.config with a location node.
In %SYSTEMROOT%\Microsoft.NET\Framework64\[framework version]\Config\web.config, add the following where Site1 and Site2 are my two applications pointing to the same physical directory:
<?xml version="1.0" encoding="utf-8"?>
<!-- the root web configuration file -->
<configuration>
<!-- App settings for the different applications -->
<location path="Default Web Site/Site1">
<appSettings>
<add key="ConnectionString" value="the cnn str"/>
</appSettings>
</location>
<location path="Default Web Site/Site2">
<appSettings>
<add key="ConnectionString" value="the cnn str"/>
</appSettings>
</location>
...
</configuration>
The web.config in the physical folder will override this appSetting so I also needed to remove it from that file.