log4net Dynamic Properties in XML Configuration.

I just learned about a new feature today of log4net that would have saved me a few hours of time had I known or been able to find this earlier.  I learned that you can have dynamic properties stored into log4net’s global context from code and then access them from the XML configuration file. This is useful in the case where dynamic configuration of log4net is needed.

My Case: I have been building console application that will run nightly to sync some integration records and I wanted to setup logging in order to see that status of the job and gather some reporting information (counts, time run, etc).  There was a catch though this process would run multiple times in a night but each time for a different customer.  This would make it difficult to read the logs for a particular customer as all I would have to go on is the file date and time.

I needed a way to break my log files into different customers yet retain the rolling file appender features of log4net.  My first pass at with was to configure log4net using the basic configurator all in code and create the appender, with a dynamic file name, and set the level of the logger programitacally. This was not my preferred way but was my only hope to getting the application out of developement. Then I found how to set properties into log4net’s global context and access them through the configuration file. I did run into a small problem that my app.config file was not being read in so I had to add these two variable to my assembly.

[assembly: log4net.Config.XmlConfigurator(Watch = true)]
[assembly: log4net.Config.Repository]

My goal was to make the file name dynamic based on the CustomerID passed into the application. Please not the file tag as it is the ticket to my case.

<log4net>
    <root>
        <level value="INFO" />
        <appender-ref ref="RollingLogFileAppender" />
    </root>   <!-- New Log File once per execution -->
    <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
        <file type="log4net.Util.PatternString" value="logs\logFile_%property{BrokerID}.txt" /> <!-- Awesomeness -->
        <appendToFile value="false" />
        <rollingStyle value="Size" />
        <maxSizeRollBackups value="-1" />
        <maximumFileSize value="50GB" />
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
        </layout>
    </appender>
</log4net>

Here is a sample of my log4net configuration section. Please note the file tag and type attribute to be log4net.Util.PatternString. The pattern of the value is important to, it must be %property{property_name} to get the right replacement. This is the ticket to dynamic values.

private static void InitLogger()
{
    //This is freaking awesome, put a property into the log4net context and using the 
    //  log4net.Util.PatternString type you can dynamically set values for the logging context from code.
    log4net.GlobalContext.Properties["CustomerID"] = (CustomerID!= 0) ? CustomerID.ToString() : "Error";
}

Here is an example of my small InitLogger. This method is the very first item to be called when the main routine starts up. All that needs to be done now is get a logger and start logging. A file will be created based on the CustomerID which in this case is retrieved from the command line arguments before InitLogger is called. If no CustomerID is passed in than the file will be to logFile_Error.txt

private static ILog Logger;   static void Main(string[] args)
{
    if (args.Length > 0)
        CustomerID= Util.GetInt(args[0]);   InitLogger();
    Logger = LogManager.GetLogger("Process");
}

Pretty cool I think, I hope this saves people some headaches. I wish I would have found this a few days ago. Oh well it is to my benefit to learn. Happy coding.

Posted in: programming problems and solutions | Tags: log4net dynamic dynamic properties dynamic property xml configuration configurator programitacally

How To Dynamically Include Files in ASP.NET

In ASP.NET, the Response object provides a new method named WriteFile. You can use the WriteFile method to write the specified file directly to an HTTP content output stream.
If you only want to write the content of a file to the browser, you can accomplish this in just one statement. If you want to manipulate the file before you send it to the browser, refer to the References section for information about basic file input/output in .NET.
In ASP.NET, you can either write inline code or write code in the code-behind module. This article presents an inline code sample that opens a file and writes the file's content to the browser.

Steps to Create the Sample

  1. Open Microsoft Visual Studio .NET.
  2. From the File menu, point to New, and then click Project.
  3. In the New Project dialog box, click Visual Basic Projects under Project Types. Under Templates, click ASP.NET Web Application.
  4. Switch to the HTML code editor for the .aspx page that is created by default. Replace the existing code with the following code:

       <%@ Page Language="vb" AutoEventWireup="false"%>
       <html>
       <body>
            <%		   
              Response.WriteFile ("Yourfile.inc")
            %>
       </body>
       </html>
    					
  5. Replace "Yourfile.inc" in the Response.WriteFile statement with the name of an include file that contains some HTML or client-side script.
  6. Add "Yourfile.inc" to the project.
  7. Browse to the .aspx file. Note that the content of your file is written to the browser.

Troubleshooting

  • Server-side code in the dynamically included file is displayed on the client browser.
    The dynamically included file may contain any client-side code, including HTML and JavaScript. If that file contains any server-side code, the server-side code is sent to the client browser as plain text and is visible if you view the source of the page that is displayed in the browser. Note that ASP.NET does not process server-side script in the dynamically included file. This is because all of the ASP.NET code has already run before it includes the file; thus, the server does not return to read anything for server-side processing again.
  • If you use Response.Write or Response.WriteFile statements in a code-behind module, these statements write the information before any HTML tags. The same behavior occurs if you use inline <SCRIPT> tags with the RUNAT="Server" attribute.
    Because the code-behind modules are compiled first, all of the output that is generated by Response.Write, Response.WriteFile, or inline server-side <SCRIPT> tags appears before any HTML tags when the HTML output is sent to the browser. This problem does not occur when you use Response.Write statements in classic ASP-style tags.
Posted in: programming asp.net | Tags: asp.net dynamic include files inc files

Web Deployment Tool has gone RTW

Microsoft is proud to announce that the Web Deployment Tool has gone  RTW version 1.0!

You can now download the RTW version and use it in production, and it is fully supported by Microsoft Support.

Install our 1.0 RTW release from http://www.iis.net/webdeploymenttool, available in x86 and x64.

Version 1.0, includes the following components:

  • Powerful APIs that allow you to deploy, sync and migrate web applications on IIS, and perform granular operations like changing IP bindings, site names and changing file structures on the fly. You can also create a new provider to sync a new type of resource.
  • Command-line tool (msdeploy.exe) that allows you to perform all the same operations available in the APIs.
  • User interface built into IIS Manager 7.0 on Vista, Windows 2008 and Windows 7 that allows you to create packages (zip files containing IIS config, content, databases and more) and install them.
  • Delegation framework and service built into IIS 7.0 that allows you to delegate tasks like installing applications and databases without requiring them to be administrators on the box.
  • Remote administrative service that works on IIS 6.0 and 7.0 to allow server-level synchronization by administrators.

So, what can you do with these components?

  • Migrate Web applications from IIS 6.0. Simplify the planning of your IIS 6.0 to IIS 7.0 migrations by determining incompatibilities and previewing the proposed changes before starting the process. Learning about any potential issues in advance gives you the chance to take corrective measures and simplifies migration.
  • Synchronize your server farm. Synchronize between IIS 6.0 > IIS 6.0 or IIS 7.0, and only sync the differences. The tool simplifies the synchronization process by automatically determining the configuration, content and certificates to be synchronized for a Web site. Optionally, specify additional resources for sync, including databases, COM objects, GAC assemblies and registry settings.
  • Package, archive and deploy Web applications. Package configuration and content of Web applications, including databases, and then use the packages for storage or redeployment. These packages can be deployed using IIS Manager without requiring administrative privileges. The tool integrates with Visual Studio 2010 to help developers streamline the deployment of Web applications to the Web server. The tool also integrates with the Web Platform Installer to allow you to simply and easily install community web applications.

Some of our favorite customer scenarios include:

  • Create application packages that contain all of the IIS config, content, databases and more, including parameters so that when the server admin installs the package, they are prompted to fill in parameters like SQL Server connection string.
  • Build an automated deployment system using our APIs, cmd-line or the Visual Studio integration, so that you can deploy daily from test to staging to production.
  • Allow your developers to directly deploy to the staging server without admin intervention, and lock down exactly what they can change (mark a folder as an app but not change the site's binding).
  • Replace Application Center with a set of scripts or programs that call our APIs or cmd-line to sync multiple servers in a web farm.
  • Build a roll-back solution by taking a package of your live app, deploying the app_v2 package created in your dev environment, and checking for failures. In case of failures, automatically apply the v1 package or backup that you took.
Posted in: programming asp.net | Tags: iis web deployment rtm package archive deploy web applications synchronize

additional changes to existing types and members for ASP.NET MVC 2 Preview 2

The following additional changes have been made to existing types and members for ASP.NET MVC 2 Preview 2.

· Removed the IsNullableValueType property from the TemplateInfo class and added it to ModelMetadata. When ASP.NET MVC looks up a template for Nullable<T>, the type of T is used for the type-based template lookup. This new property lets the template author know that the original value was a nullable type.

· Changed the Controller.Execute method to throw an exception when it is called more than once on the same instance. Controllers are meant to serve a single request and to be executed only once. Many developers were running into subtle bugs when they accidentally set an Inversion of Control (IoC) container to return a singleton instance of a controller rather than a new instance per request. This change makes the contract for controllers explicit.

· Changed templated helpers to return their output as a string rather than writing the output directly to the response. Before this change, the helpers returned an empty string and wrote their output directly to the response.

· Changed the Controller class so that it no longer inherits from MarshalByRefObject.

· Added support for the DataType.Password enumeration value for the DataTypeAttribute class. When a property is marked with this attribute, the default editor template will render a password input element.

· Made the AuthorizationContext(ControllerContext context) constructor obsolete. Instead, use the constructor that accepts both a ControllerContext parameter and an ActionDescriptor parameter.

· Made performance improvements to expression-based helper methods such as the template helpers. Helpers now cache compiled LINQ expressions.

· Added TemplateInfo.GetFullHtmlID and Html.GenerateIDFromName methods that are used to generate the recommended HTML id attribute value for an element within a template. This helps template authors make sure their templates work when they are nested in other templates.

· Added new attributes for simple REST scenarios, including HttpPutAttribute, HttpDeleteAttribute, and HttpGetAttribute. For more information, see Overriding the HTTP Method Override Verb earlier in this document.

· Changed the default editor template for nullable Boolean values to render a drop-down list that has three options: “Not Set”, “True”, and “False”. When “Not Set” is selected, the value that is submitted to the server is an empty string.

· Changed model types so that they can be either value types or reference types. This allows view pages and other types to support built-in .NET Framework value types such as System.DateTime and System.Int32.

· Changed the framework so that if a controller namespace is specified as part of a route registration (for example, by using the namespaces parameter in a call to the MapRoute method), the framework now looks in that namespace and its children for potential controller matches. For example, if the namespace MyNamespace is specified, the framework will look in the equivalent of MyNamespace.* for a matching controller.

· Renamed the htmlFieldPrefixId parameter for the template helper methods to htmlFieldPrefixName, and renamed TemplateInfo.GetFullHtmlFieldId renamed to TemplatInfo.GetFullHtmlFieldName. The new names better represent the purpose of the parameter and property.

Posted in: programming asp.net | Tags: asp.net asp.net mvc mvc 2 preview 2 httpgetattribute httpdeleteattribute marshalbyrefobject templateinfo getfullhtmlid generateidfromname nullable htmlfieldprefixid getfullhtmlfieldname

Windows Management Instrumentation

Windows Management Instrumentation (WMI) is the infrastructure for management data and operations on Windows-based operating systems. You can write WMI scripts or applications to automate administrative tasks on remote computers but WMI also supplies management data to other parts of the operating system and products, for example System Center Operations Manager, formerly Microsoft Operations Manager (MOM), or Windows Remote Management (WinRM).

Where Applicable

WMI can be used in all Windows-based applications, and is most useful in enterprise applications and administrative scripts.

System administrators can find information about using WMI at the TechNet ScriptCenter, and in various books about WMI. For more information.

The Developer Audience

WMI is designed for programmers who use C/C++, the Microsoft Visual Basic application, or a scripting language that has an engine on Windows and handles Microsoft ActiveX objects. While some familiarity with COM programming is helpful, C++ developers who are writing applications can find good examples for getting started at Creating a WMI Application Using C++.

To develop managed code providers or applications in C# or Visual Basic .NET using the .NET Framework, see WMI in .NET Framework.

The WMI Software Developer Kit (SDK) is available as a download that includes documentation at the Download Center. The WMI Redistributable Components version 1.0 file, is required only for Windows 2000 and is available to download at the same location.

WMI functionality introduced in the Windows 2000 Professional with Service Pack 2 (SP2) operating system is also available to earlier operating systems by downloading the .NET Framework SDK, and the .NET Framework Redistributable. These can be obtained at http://msdn2.microsoft.com/en-us/netframework/aa731542.aspx.

Overview Run-Time Requirements

For more information about which operating system is required to use a specific API element or WMI class, see the Requirements section of each topic in the WMI documentation.

If an expected component appears to be missing, see Operating System Availability of WMI Components.

Posted in: programming | Tags: c# introduction intro wmi overview