Technology

Back in the world of blogging, just moved.

Martin Granell — Thu, 18 May 2006 14:10:00 GMT

New blog home: http://granell.net/martin

Its been a while, but I now have my blogging fingers primed, after a long absence, having been very busy offline these past few months. I will also be putting up my demos and slides from the various user groups/conferences I've been at during this time, so see you there.

Wah.Onterra is dead, long live Granell.NET

Yours,

Martin

#! /usr/bin/vbc support for windows script (or self-compiling .NET scripts)

Martin Granell — Tue, 09 Aug 2005 11:27:00 GMT

This post and comments can now be found on my new blog here

One of the “nice” things about the unix shell is the ability to create a script file that contains the program that will run the script at the top of the file. This allows all kinds of extensibility in the shell, and the ability to plug in your favourite script interpreter. This post shows how to create the same effect for .NET 1.1 on windows.

I was just reading Ken Schaefer’s blog about using Windows Scripting Host, and it reminded me of some old code I had written that was a self-compiling VB.NET WSF script. An example script is below:

' vbc /r:System.Windows.Forms.dll
'<job id="IncludeExample"><script language="JScript">var WshShell = WScript.CreateObject("WScript.Shell");var filespec = WshShell.ExpandEnvironmentStrings("%TEMP%")+"\\" +WScript.ScriptName+".exe";var fso=WScript.CreateObject("Scripting.FileSystemObject");if (fso.FileExists(filespec)) fso.DeleteFile(filespec);var ts=fso.OpenTextFile(WScript.ScriptFullName, 1);var comp = ts.ReadLine();comp=comp.substring(comp.indexOf(" ")+1);ts.Close();var f=fso.GetFolder(WshShell.ExpandEnvironmentStrings("%windir%\\Microsoft.NET\\Framework\\"));if (!f) WScript.Echo("You must have the .NET Runtime installed");var netVersion="";fc = new Enumerator(f.SubFolders);for (;!fc.atEnd(); fc.moveNext()){if (fc.item().name > netVersion)netVersion = fc.item().Path;}oExec = WshShell.Exec(netVersion + "\\" + comp + " /out:"+filespec+" /target:exe /debug "+WScript.ScriptFullName);while (oExec.Status == 0){if (!oExec.StdOut.AtEndOfStream){WScript.Echo(oExec.StdOut.ReadAll());}WScript.Sleep(100);};if (!oExec.StdOut.AtEndOfStream){WScript.Echo(oExec.StdOut.ReadAll());}if (!fso.FileExists(filespec)) WScript.Quit(1);oExec = WshShell.Exec(filespec);while (oExec.Status == 0){if (!oExec.StdOut.AtEndOfStream){WScript.Echo(oExec.StdOut.ReadAll());}if (!oExec.StdErr.AtEndOfStream){WScript.Echo(oExec.StdErr.ReadAll());}WScript.Sleep(100);};if (!oExec.StdOut.AtEndOfStream){WScript.Echo(oExec.StdOut.ReadAll());}if (!oExec.StdErr.AtEndOfStream){WScript.Echo(oExec.StdErr.ReadAll());}</script></job>
'
' A "Hello World!" program in Visual Basic.
Imports System
Imports Microsoft.VisualBasic
Imports System.Windows.Forms
Module Hello
   Sub Main()
        ' Console class from .NET
        Console.Write("To the console...")

' Intrinsic VB compatible code
MsgBox("Hello World!") ' Display message on computer screen.

        ' Example of using the shell object
        Dim shell as Object = CreateObject("WScript.Shell")
        shell.Popup("hello2")

        ' Example of using a referenced assembly
        MessageBox.Show("This is using System.Windows.Forms")
    End Sub
End Module

The magic in this script comes from the second line, which contains a valid WSF fragment. It is also VB.NET commented, so that the file is a valid VB.NET file. The code searches for the latest version of the .NET runtime, reads the first line of itself for the compiler and any additional arguments (e.g. references to other assemblies), compiles the .exe into the TEMP directory, and then runs the executable, making sure to copy standard out and error out into the console window.

To run the example, copy it into a file named foo.wsf, and run:

cscript foo.wsf

If you wanted to use the c# compiler instead, it would be a small matter of changing the compiler in the first line, and making the code compatible (of course you couldn’t use the late binding support available within VB.NET). Now you have the full power of .NET without having to run the compiler manually…

Enterprise Library Demo from tonights user group meeting

Martin Granell — Fri, 18 Feb 2005 00:27:00 GMT

This post and comments can now be found on my new blog here

Hi folks,

Here’s the web service that I demoed tonight. This web service provides an authenticated and instrumented web service that uses a persistent, encrypted database cache to support web farm caching of generated results in 60 lines of code. It also (coincidentally) makes use of every one of the Enterprise Library application blocks directly, or through configuration.

You can download the demo here. The powerpoint file can be found at the Enterprise Library gotdotnet workspace (under releases on the right-hand side), this is a direct link to that file.

To run, ensure that you have created the Caching and Security databases (by running the .cmd files in the Enterprise Library source). Add a user “martin”, password “martin” using the SecurityDatabaseConsole.exe program. Make sure that the ASPNET account has access to the databases. You may also need to run the “Install Services” script to register instrumentation sources.

Declarative security with Enterprise Library (The Real Thing)

Martin Granell — Thu, 10 Feb 2005 00:42:00 GMT

This post and comments can now be found on my new blog here

Lets start off with Why bother to use declarative security attributes? It’s only a few more lines of code to write:

public void DoSomethind()

{

IAuthorizationProvider prov = AuthorizationFactory.GetAuthorizationProvider();

if(!prov.Authorize(Thread.CurrentPrincipal, "important stuff"))

{

throw new SecurityException("Not allowed to do this");

}

Versus:

[AuthorizationPermission(SecurityAction.Demand, Context = "important stuff")]

public void DoSomethind()

{

}

But there are two main advantages to the attribute approach (as well as reduced LOC, and cleaner code):

1. The ability to read the metadata. Permview is an example of an application that can read the meta data from an assembly, and spits out the following for the method above:

Method AuthTest.Class1::DoSomethind() NonCasDemand permission set:

   <IPermissionclass="Readify.EnterpriseLibrary.Permissions.AuthorizationPermissionXml, Readify.Entlib.Permissions"
                version="1"
                unrestricted="False"
                context="important stuff"/>

</PermissionSet>

This then allows us to scan all the assemblies in the application, and build up a manifest of which methods are protected by which authorities.

2. Flexibility – If we want to add additional logging to our attribute, or change the factory behaviour, we have one level of isolation from the underlying authorization source (in this case enterprise library).

OK, well how do we build one? Have a look at the source from here to see a finished custom non-code access security attribute. See this post for an overview of the process.

There are a few tricks to know:

1. The attribute must derive from CodeAccessSecurityAttribute, even if it is not a CAS attribute. If it just derives from SecurityAttribute, then the C# compiler will ignore it (although the VB.NET one does the right thing…)

2. The ToXml() method must create an element with the name IPermission, and there must be a class attribute with the assembly qualified name.

3. The assembly must be strongly named, otherwise you won’t get the compiler to emit the permission.

4. The assembly must either be added to the GAC, or to the Visual Studio devenv.exe directory, for the VS.NET compiler to find it (although the command line compiler does not have the same problem).

5. The attribute must have a single constructor which takes a single SecurityAction parameter. Don’t be tempted to provide multiple parameters to initialize the attribute instead.

6. The debugger is your friend. Debug visual studio by launching it in the program arguments of the project debugging properties, and step through what your permission and attribute is doing.

7. Reflector is critical. When things start going wrong, the error messages are usually totally irrelevant. Look at the implementation of PermissionSet in reflector, and use permview to dump the XML that your attribute created.

8. Unit tests. Unit tests. Unit tests. Unit tests. Did I mention unit tests?

Now, point number 3 was that the assembly had to be strong named. Since we want to call the authorization interface in enterprise library, and the default installation of enterprise library is not strong named, this is a problem.

Well… back to reflection land. I’ve created three wrapper classes, that on class constructor dynamically load the weakly named enterprise library using an assembly string, using reflection to grab MethodInfo instances for each the types, and then has some public wrapper methods that invoke the method infos.

Performance should not be too bad, and should be outweighed by the real authorization costs being performed anyway. From a security perspective (Trojan succeptability), this is no worse than using the IAuthorizationProvider interfaces directly, if the enterprise library assemblies being used are not strongly named.

If you do strongly name your enterprise library, then you can rip out the wrappers, and the calls to the wrappers, and replace with direct calls to the enterprise library factory and interfaces.

New release of String Resource Generator with multi-language SR.strings support

Martin Granell — Wed, 09 Feb 2005 22:33:00 GMT

This post and comments can now be found on my new blog here

UPDATE: There was a problem in the previous release. Method (b) would not work (thanks to VS.NET for not handling satellite assemblies correctly..). I've updated the instructions below, and the sample in the release, to cover what needs to be done to make it work:

Hi Folks,

The next release (~~1.2.2~~ 1.2.3) of the string resource tool is here… Changes for this release are:

1. More complete sample, that should cover all of the functionality of the Custom tool and Batch .exe

2. Accessibilty option now works (with VB.NET & C# only at this point, otherwise it can only be public, blame CodeDom).

3. The Resource class generation can be turned off by using “generate_class = false”

4. SR.strings files can now contain multi-line resources, by doing the following:

[strings]
ResName(int age) = First Line
= Second Line {0}
= Third Line
NextRes = Blah

5. From release 1.2.1 onwards its possible to use 3 methods of having multiple locales resources in the same project.
(a) Have a primary .resx file (e.g. SR.resx), with the CustomTool option set. Have secondary .resx files (e.g. SR.de.resx, SR.en.us.resx), which do not have a custom tool set.

b) Have a primary SR.strings file, with one [strings] section with all the neutral resources, with the CustomTool set. Have secondary .strings files (e.g. SR.strings-de) _with_ the Custom Tool set, but with “#! generate_class = false” at the beginning of all the secondary .strings files, and locale dependent [strings] sections, e.g:

SR.strings:
[strings]
ResName = blah

SR.strings-de:
#! generate_class = false
[strings.de]
ResName = German blah

SR.strings-de-DE:
#! generate_class = false
[strings.de-DE]
ResName = German in Germany blah

Note: The extension on the secondary strings files can be anything, but the base filename must be the non-localized resource name. i.e. SR.de.strings is not valid because the base name is “SR.de“. SR.strings-de is valid, because the base name is “SR“.

c) Multi-locale .strings file. Have a SR.strings file with multiple [strings] sections, one for each locale. e.g.
[strings]
Res1 = Text
...

[strings.de]
Res1 = German Override
...

[strings.de.DE]
Res1 = Germany override
...

Note that you can combine all of these options if you wish. E.g. a primary SR.strings file with:
[strings]
[strings.en]
[strings.en.US]

And a secondary SR.strings-de file with:
#! generate_class = false
[strings.de-DE]
[strings.de-CZ]

which will generate:
SR.de-DE.resx
SR.de-CZ.resx

Declarative security with Enterprise Library

Martin Granell — Thu, 03 Feb 2005 23:35:00 GMT

This post and comments can now be found on my new blog here

UPDATE: ok, so it's tomorrow, and I haven't done the post... however I have uploaded the files. You can get the source here. Tomorrow, I promise, I'll put up a post describing how I built the code, what issues there were, and how to use it.

Tomorrow I’ll be posting some code I’ve been working on that allow the use of declarative attributes to secure blocks of code, and uses Enterprise Library’s authorization model to do so. An example line in VB.NET would be:

< AuthorizationPermission(SecurityAction.Demand, Context:="OrderBooks" > _
Public Sub OrderBooks()
 
End Sub

This is somewhat equivalent to the PrincipalPermission attribute, but uses (in this case the default) IAuthorizationProvider instance obtained through the enterprise library provider model.

The code will show a few things:

1) How to use the authorization API of enterprise library

2) How to build custom security attributes

3) How to get around the problem of security attributes having to be strong named, but the default install of enterprise library does not use strong naming. (Remember that a strongly named assembly may only reference other strongly named assemblies).

This can be used as part of a defence in depth strategy, typically to secure business methods. One of the great advantages to using security attributes is the ability to use permview to dump which methods in which assemblies require which authorities. This allows a high degree of security visibility and checking.

String Resource Generator v1.2 now with support for Enterprise Library SR.strings files

Martin Granell — Tue, 01 Feb 2005 14:12:00 GMT

This post and comments can now be found on my new blog here

UPDATE: All future updates and comments will be at the project distributor website, as that contains an RSS feed and comment system...

I originally wrote the resource generator to run off a .resx file, but I’ve now updated the tools with two important changes. You can download the source and samples from here (with installer included):

An example SR.strings file can be found here.

Firstly, there is now a command line .exe, SRGenerator.exe, which can be used by doing the following command line:

SRGenerator.exe

codeProvider vb, cs, or CodeDom Provider assembly qualified class name.
namespace Namespace.
file File name, either a .strings file or a .resx file.

Secondly, the tool can now parse the SR.strings file, which is the one of the string resource file format used within Microsoft. It will generate a SR.resx file, and the SR class to use the resource. This means that if you want to edit the enterprise library resources, just run this installer, and then you can edit the library to your hearts content.

The changes to the tool are the following:

It registers itself under both the SRCodeGen custom tool (my original name), and the StringResourceTool (used in the enterprise library source).

If the file that the custom tool is set on is not a resource file then it converts the file (in the format of the SR.strings file) into a resource file, and adds the file to the project underneath the .strings file, by doing the following:

1. Converts all options into resource file headers, e.g. #! culture_info = Resources.CultureInfo, becomes a header named “culture_info”, and with the value “Resources.CultureInfo”.

2. Converts all entries in the [strings] section into resources, with the name of the resource being the first part of the line, the value of the resource the part after the = sign, and the comment of the resource being anything in brackets after the name.

The resource file is then processed according to the rules of my original post, with a couple of changes:

· The comments denote the parameter names and optionally types of any arguments in the value (given as String.Format arguments). If there are no argument names specified in the comment, then the resource accessor generated will not use String.Format to replace any parameters in the resource. This allows having resources with un-replaced positional specifiers in them.

· The following options (specified as resource headers) are implemented:

i. culture_info : If specified, then this will be copied verbatim into the generated file as part of the call to ResourceManager.GetString(name, …). If not specified, then a public static Culture property is added to the SR class to allow changing the culture manually.

ii. accessor_class_accessibility: If this value is “public”, then the SR class will be public, otherwise it will be internal.

This uses CodeDOM, and so supports VB.NET as well as C#.

Windows Integrated Security Providers for Enterprise Library

Martin Granell — Tue, 01 Feb 2005 02:00:00 GMT

This post and comments can now be found on my new blog here

Over the next few weeks, I’ll be posting code samples, patches, tips and tricks for using enterprise library. I’m currently in the middle of building a course which uses Enterprise Library as the implementation for a lot of the patterns the course teaches, and so I hope to share some of the knowledge I’m gleaning, some sample code, and hopefully some useful extensions to the library.

The first cab off the rank is a couple of security providers. These are really more examples of how to extend the security application block, but they are useful in their own right. They also demonstrate how to hook into the new configuration console.

Firstly the download location, and the place I’ll be putting all the code samples until the community site for enterprise library appears:
http://projectdistributor.readify.net/Projects/Project.aspx?projectId=3

You’ll find the source there, along with some unit tests.

The two providers wrap the functionality given by LogonUser, the WindowsIdentity class and the WindowsPrincipal class. The API for authentication and roles in enterprise library looks like this:

IAuthenticationProvider authProvider = AuthenticationFactory.GetAuthenticationProvider();

NamePasswordCredential credentials =
new NamePasswordCredential(@"UNKNOWN\bogart","password");

IIdentity identity;

if (authProvider.Authenticate(credentials, out identity))

{

IRolesProvider roleProvider = RolesFactory.GetRolesProvider();

IPrincipal princ = roleProvider.GetRoles(ident);

// Do stuff with IPrincipal, e.g. Thread.CurrentPrincipal = princ

}

Now, if we just wanted the current windows identity, we could have passed null instead of some credentials.

If we were just trying to get the current user’s identity, then you would think, let’s just do:

WindowsIdentity ident = WindowsIdentity.GetCurrent();

IPrincipal princ = newWindowsPrincipal(ident);

// Do something with the principal.

But the advantage is that the provider that is used is configuration driven, and with the shiny new configuration tool that comes with enterprise library, configuration is a breeze. See Scott’s post about the configuration tool.

So the reason why the Windows security providers can be useful is that we can immediately start using the provider model in our application, and then swap out the integrated providers for some custom authentication / roles providers in the future.

I’d be interested what people think, and whether these sorts of samples are useful or not.

Enterprise library is out of the box

Martin Granell — Sun, 30 Jan 2005 01:42:00 GMT

This post and comments can now be found on my new blog here

Congratulations Tom, and the entire group involved for putting together a coherent library of extremely useful pluggable blocks. I have it on good authority that they were up until 2am last night getting it out the door :P

You can grab it from here, but you’ll have to register.

For me, the biggest change from the mishmash of the application blocks is useability. While there was great technical functionality in the original blocks, details such as the ability to configure up the end application, consistent documentation and deployment/versioning considerations hadn’t been reached yet.

With the configuration console, and the “configuration time” experience (rather than the design time experience in the IDE), we now the ability to give system administrators, or deployment customizing development teams a user interface to select which providers they need, where to store configuration information, what level of encryption, etc. all without touching a single line of XML. See Scott Desnmore's blog for a preview of the configuration console.

Now I know there will be a few tears… I’ve had the joy of cutting and pasting XML configuration files over the past year. Watching configuration exceptions appear when I’ve pasted that invisible tab character in from an internet explorer window, tracking down what QName I needed for WSE2, using reflector to see exactly what was happening inside EIF when it didn’t like my configuration…

Enterprise library is missing some functionality compared to the set of application blocks it replaced. Most of the functionality missing was obviously a conscious design decision. Some looks like it is just due to time. But they have concentrated on quality and coherent functionality rather than getting the kitchen sink in.

For those that like kitchen sinks (like myself), there will be a community site coming along, but I’ve got a few things that I’ve created that I’ll be posting. Keep tuned.

Again, thank you to everyone involved for the obvious effort that has been put in to providing, for free and with source and documentation, a set of very useful building blocks for .NET application development.

.NET User interface for Tracking down managed memory leaks

Martin Granell — Mon, 20 Dec 2004 10:05:00 GMT

This post and comments can now be found on my new blog here

From Mitch's blog, I got to read Rico Mariani’s post the other day, and I noticed a couple of comments suggesting automating the process he described there. Being somewhat of a debugger hack, I thought it would be good to put together a user interface that drives the debugger process, parses the output, and provides an easy way to explore an application’s heap. The result is below:

One of the trickiest bits was allowing the application to continue, and then break, as the debugger requires Ctrl-C to be sent to the console window. I’ve also multi-threaded the console tracing, as that was proving to be a bottleneck. The application demand loads information as the user clicks around, and caches it until the next breakpoint.

I’ve included an updated product support SOS DLL, psscor.dll, as it provides much better information when dumping objects. This can be found at:

http://blogs.msdn.com/mvstanton/archive/2004/04/05/108023.aspx

You can get the source and binaries from here. Usage instructions are included, as detailed below:

Instructions for use:

· Install Debugging Tools for Windows (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)

· Change the application configuration file to point to your installation.

· Fire up the application.

· Use File->Connect to Process to select the process to attach to.

· This will suspend the process and dump out a list of all the types currently running, with size and instance count.

· Click on a type, and it will list all the instances in the top right-hand corner.

· Click on an instance, and it will search for all the GC roots that can get to the object, and list the count of them.

· In the "Roots" combo-box, it will list all the roots.

· Selecting a root in the "Roots" combo box will show the trace of objects from the object to the instance selected.

· Click on an object in the trace, and its details will be dumped into the text box.

You will also notice a console window. This shows a trace of all the debugger communication, and is required to allow the application so send Ctrl-C commands to the debugger (to allow continue & break to work). It's also nice to see what's going on behind the scenes.

You can continue the application by going to Debug->Continue, and break again by using Debug->Break. You can also send the debugger explicit commands by typing in the "Send Debugger Command" text box, and hitting return. The output will appear in the textbox under the GC trace, as well as in the console window. I wouldn't recommend sending the "G" (go) command, as the application will probably freeze. Please use the Debug menu to “continue”, “break” & “detach” the application.

Future enhancements I’m thinking about:

· Parse the output of the object dump to allow jumping to other objects referenced from the object (and viewing GC trace etc.)

· Dump out the entire info-set as XML for post-processing (not sure about whether to dump out all the demand loaded GC traces though, maybe only dump out one set of type instances, or a tree?)