I am running NServiceBus and having this issue. To try and troubleshoot it I would like to make NServiceBus log to a file.
The problem is that I am hosting NServiceBus in IIS, not NServiceBus.Host.exe. Because of that I don't know a way to turn on the the production profile.
Is there a way to tell NServiceBus to log to a file not using profiles? (Or a way to set the profile when not using NServiceBus.Host.exe?)
I had hoped that there is a way change NServiceBus.Configure.With().Log4Net(); to put an Appender in that will log to a file. But I don't see anyway to do that in code (all the examples use xml).
Alternatly if there is a way to change this to log to a file that would be great too:
<configSections>
<section name="Logging" type="NServiceBus.Config.Logging, NServiceBus.Core" />
</configSections>
<Logging Threshold="FINE" />
Does anyone know how to do either of these things?
Implement IWantCustomLogging:
https://github.com/NServiceBus/NServiceBus/blob/master/Samples/GenericHost/LoggingFromAppConfig/EndpointConfig.cs
And specify the RollingFileAppender in code:
Configure.Log4net< RollingFileAppender>(...)
Related
I am using mvc5 for application my local system application is working properly. but I upload publish file then server shows error show
Would be nice if anyone helps about it
Without seeing more code, it is hard to tell, but at a guess, you may want to look into your config file(s) and particularly the transformation side of this value in app settings.
<add key="ClientValidationEnabled" value="true" />
It may have an incorrect value which cannot be parsed, which is why the error is occurring down the stack after "get_clientvalidationenabled" is called.
This seems like a relatively simple question, but I didn't see it clearly indicated in the documentation I examined. Assuming a typical Elmah usage on a Windows Server 2012/IIS 7 webserver installation, if the Elmah web.config settings are pointed to an Elmah.config file, will altering that file trigger under the running application cause IIS to restart?
While the answer provided by Josh would normally be true, it is not in the case of ELMAH. ELMAH instantiates a new error log implementation every time it is needed, reading the configuration from either web.config or the configSource provided.
You can do a simple test to prove this. If you configure ELMAH to use an external config file for the errorLog element like this:
<elmah>
<errorLog configSource="elmah.config"/>
</elmah>
and your elmah.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data" />
When you start the project and force an error, a new XML file is written to the App_Data folder. Change the logPath like this (without restarting the application):
<?xml version="1.0" encoding="utf-8"?>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data2" />
(I changed to App_Data2).
Force a new error and you will now see ELMAH create the App_Data2 folder on the file system.
No: Straight from MSDN:
Saving a Web.config file restarts the application. You can alternatively use the configSource attribute of individual section elements to point to a secondary configuration file that does not cause an application restart when it is changed. For more information, see configSource in General Attributes Inherited by Section Elements.
MSDN
I have log4net setup just like in the examples. In my config file, I have:
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
The appender configuration is setup just like it is shown on the log4net site for MS SQL Server surrounded by <log4net>. http://logging.apache.org/log4net/release/config-examples.html
In the AssemblyInfo.cs I have:
[assembly: log4net.Config.XmlConfigurator]
Yet, nothing is showing up in my [dbo].[Log] table.
I have tried using the trace debugging text file, but no errors show up there.
The reason why no errors were showing up in the trace file is because no errors in log4net were happening.
The reason why there was nothing showing up in the [dbo].[Log] table was because the default config on the l4n site has <bufferSize value="100" />. It is my understanding that this bufferSize would mean that l4n would wait until there are 100 messages queued up before writing them to the database. So, to fix it for me, I just changed the value to "1".
has anyone successfully added IIS script maps to their Wix installation. I have been using this:
<CustomAction Id="AddHandlers_Cmd" Property="AddHandlers" Value=""[SystemFolder]inetsrv\appcmd" set config -section:system.webServer/handlers /+"[\[]name='GSOAP',path='*.dll', verb='*',modules='IsapiModule',scriptProcessor='[BIN]mod_gsoap.dll',resourceType='File', requireAccess='Execute'[\]]"" Execute="immediate"/>
<CustomAction Id="AddHandlers" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>
However I get the 404 errors from my web application and when I add the script map manually after installing the application it works perfectly. I would appreciate if anyone could share how they done this.
It sounds like you need to add handler mapping to your web application. If that's the case, then you don't need a custom action to accomplish this.
Take a look at WebApplicationExtension element.
We are writing a separate Custom action in C# and Schedule it in after install Finalize to add handlers.
Try this, you can do anything with your own custom action.
I haven't worked with GSOAP handler, but used ASP.NET ISAPI extention. I suppose basically it has the same level of integration. I will post the code for ASP.NET and I hope you won't have problem with changing it to GSOAP. I have a huge risk of changing something incorrectly and make the examples unusable for you, so I let you do it better.
Here is my code to register extention itself if it isn't
<Component Id="Iis6ConfigExtentions" Guid="{GuidHash({ProductId}-1822E4F3-5850-47D5-9281-D1E0E20C77D4)}" KeyPath="yes" Permanent="yes">
<Condition><![CDATA[Installed OR (IISMAJORVERSION AND (IISMAJORVERSION = "#6"))]]></Condition>
<iis:WebServiceExtension Id="ExtensionASP4" Group="ASP.NET v4.0.30319" Allow="yes" File="[FRAMEWORKROOT]v4.0.30319\aspnet_isapi.dll" Description="ASP.NET v4.0.30319"/>
</Component>
and for adding those to the concrete site you need to use WebApplicationExtention, as #Yan already mentioned:
<iis:WebApplication Id="IIS6WebApp" Name="[SITE_APP_NAME]" WebAppPool="AppPool" >
<iis:WebApplicationExtension Verbs="GET,HEAD,POST" CheckPath="no" Script="yes" Executable="[FRAMEWORKROOT]v4.0.30319\aspnet_isapi.dll" />
</iis:WebApplication>
The CheckPath="no" is required on IIS 6 because we use ASP.NET MVC which doesn't map urls to files on disk. You might need it too since service address probably doesn't map to physical file.
UPDATE:
Looks like it is really not possible to do it directly in WIX (at least in 3.5 version). You are going in right direction - custom action using appcmd. But the provided custom actions aren't complete or what you need: the first one just sets property value to the command you need to execute and the second one calls some Dll custom action which wasn't provided.
What I'd try to execute is:
<CustomAction Id="AddGsoapHandler" Directory="TARGETDIR" Impersonate="no" Execute="deferred" Return="check" ExeCommand="[SystemFolder]inetsrv\appcmd.exe set config -section:system.webServer/handlers /+"[\[]name='GSOAP',path='*.dll', verb='*',modules='IsapiModule',scriptProcessor='[BIN]mod_gsoap.dll',resourceType='File', requireAccess='Execute'[\]]" /commit:apphost" />
Please pay attention to the path attribute of your handler configuration. It will limit handler usage to only URL's which ends with ".dll" - I just copied it from your code but not sure if you've done it intentionally or just copied from example at Microsoft site. That might have led to 401 error even if handler is registered successfully.
Also I added the /commit:apphost argument. Not sure if you really need this, but I use it to explicitly specify that I need to configure my application's config.
UPDATE 2:
If you need to set configuration to only single application, you should specify application object as argument of appcmd instead of the 'config' which means global configuration. Please try this:
<CustomAction Id="AddGsoapHandler" Directory="TARGETDIR" Impersonate="no" Execute="deferred" Return="check" ExeCommand="[SystemFolder]inetsrv\appcmd.exe set app "MySite/app1" -section:system.webServer/handlers /+"[\[]name='GSOAP',path='*.dll', verb='*',modules='IsapiModule',scriptProcessor='[BIN]mod_gsoap.dll',resourceType='File', requireAccess='Execute'[\]]" /commit:apphost" />
For more details you can read this tutorial.
I am using log4net during my development, as as part of a project constraint, I now need to add it to the Global Assembly Cache.
The logging definitions are in a file Log4Net.xml. That file is referenced in my assemblyinfo as: [assembly: log4net.Config.XmlConfigurator(ConfigFile = "Log4Net.xml", Watch = true)]. So long as the xml file was in the same directory as the log4net.dll, everything has been working fine.
However now that I've added log4net to the GAC, it is no longer picking up the xml file.
Does anyone know what I need to change in order to have it pick up the XML file again? Is hardcoding the patch in the assembly reference the only way?
Many thanks
log4net expects the config file to be in the path returned by:
System.AppDomain.CurrentDomain.BaseDirectory
Let your application print this information to some file and then you know where you need to place the config file.
Of course there are other solutions, but then you cannot use the attribute anymore. Calling the ConfigureAndWatch() method directly allows you to figure out yourself where the config file is; you can even decide on a location (does not have to be a hard-coded path).
You might ensure that your log4net.xml file is set to "Copy Always" (Right Click on log4net.xml -> Properties -> Copy to Output Directory = Copy always). To ensure that your config file is being copied, you should check your bin\debug or bin\release directory and verify that the log4net.xml file exists in the same directory that your application executes.
If that doesn't workthen you can try enabling internal debugging in log4net. To enable internal debugging, add the following key to your app.config file. This will send internal log4net debug messages to your Visual Studio Output window (View -> Output).
<configuration>
<appSettings>
<add key="log4net.Internal.Debug" value="true"/>
</appSettings>
</configuration>
For more information on log4net's internal debugging, you might check Phil Haack's blog post here.
If all else fails, you can turn on internal debugging and explicitly load the configuration by calling log4net's XmlConfigurator.ConfigureAndWatch method.
var fi = new FileInfo(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\\log4net.xml");
XmlConfigurator.ConfigureAndWatch(fi);