You can find it here

I worked on addressing these problems and the result is publised on MSDN Code Gallery here.

Grzegorz Gogolowicz

Senior Solutions Architect, Microsoft

Trent Swanson and I recently published a whitepaper on using SQL Server Reporting Services to generate reports that overlay data on form images. You can read it here. The sample is published on MSDN Code Gallery here.

Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 support a rich security model that allows administrators to control access to sites and content by assigning permissions to users and groups for a specific securable object (such as site, list, library, folder and even an individual document or item).

However, in certain scenarios there is a need to secure access to individual columns in lists or document libraries. Currently, SharePoint does not provide out of the box support for securing columns or views. A typical scenario that would require this might be a list that contains a broad spectrum of information about an employee or a client, where certain columns (salary, revenue to date, potential to promote, etc.) might ideally only be viewable by certain groups within the portal.

To address those scenarios, Matthew Dressel and I authored a paper that describes a method to leverage SharePoint extensibility and built-in item to level security to allow applying column-level permissions to a custom field type. This is accomplished through the use of a lookup field as the column, with behind the scenes ties to another list that contains the secure values and a method to provision those values back to the lookup only for users with valid permissions.

The result is that in the view mode authorized users will see the content of a secure column as if it was a normal column, while unauthorized users will not see the content of the column at all. This different behavior is shown in Figure 1. Similarly, only authorized users will be able to access the content of a secure column in new and edit modes.



You can read the full article at https://www.infoq.com/articles/Dressel-Gogolowicz-wss-security.

The source code for the solution can be found at https://code.msdn.microsoft.com/SecureField.

However, in this post I will focus on one finding that resulted from reviewing the product of this ISV from scalability perspective.

The reviewed server product works on Windows Server, but when I drilled into the architecture of one of the components, I learned that it originated in the previous generation of this product that was based on UNIX. This server component was responsible for handling requests from client applications and the ISV wanted to support hundreds of concurrent users. So I started asking questions suspecting that this component might have followed patterns characteristic for applications that originated many, many years ago in UNIX world. And I was right – this component was spinning a new OS process for each concurrent user. So when handling 200 concurrent users, there would be 200 processes created. So I explained to the ISV that this is not the best way to achieve top scalability on Windows platform. I pointed out that when components are migrated from UNIX to the Windows platform, there are some important differences in the OS process paradigm that need to be considered. Creating a new process in Windows is a relatively expensive operation while creating a new thread is not as expensive in terms of system resources like memory and time. And the concept of a thread pool allows reusing threads, thus reducing the existing overhead of thread creation. It doesn’t mean that every multiprocess-oriented application on UNIX that is being migrated to Windows should be re-architected to use threads instead. It depends on many factors, for instance the number of processes being created, frequency of process creation etc. But it is probably a safe bet that a UNIX application that creates dozens or hundreds of processes should be rearchitected to use threads from a thread pool on Windows. More information about process and thread management in context of migration of UNIX applications to Windows can be found in this article on TechNet. A functional comparison of UNIX and Windows is covered in this article on TechNet.

In case of this ISV I actually ended up recommending not just switching to using threads from a thread pool, but to use a thin layer of WCF-based services for cross-machine communications. These services would interop through P/Invoke with the existing unmanaged code, so it wouldn’t require any significant rewrite. My recommendation was based on several factors, such as the fact the implementation of the component being reviewed was vulnerable to buffer overrun attacks, didn’t support firewalls, run with admin privileges which created additional security risk and relied on security through obscurity.  But this is a topic for another post.

Grzegorz Gogolowicz

Senior Solutions Architect

GISV Architecture Team

 Unfortunately SxSTrace tool is not available on Windows Server 2003, so I couldn’t use it to diagnose the problem.

 I knew from my earlier development that typically if you don’t use consistent definition of assembly identity between the client manifest and the manifest embedded in the dependent assembly you gets the following event entry: “Component identity found in manifest does not match the identity of the component requested”. But I was getting a different error, so I thought that the source of the problem is not related to mismatched assembly identities. And I knew that if you made a syntax error in the manifest file, the event log entry will state it very clearly, for instance “The element assemblyIdentity2 appears as a child of element urn:schemas-microsoft-com:asm.v1^dependentAssembly which is not supported by this version of Windows”. But again, I was getting a different error. After many attempts to get it working I finally noticed that the assemblyidentity element in the client assembly had the language attribute specified as “language="neutral". But my embedded assembly didn’t! And that was the problem! Apparently SxS loader in Vista is able to match an assembly identity with “language="neutral" attribute specified with an assembly identity that doesn’t have this attribute specified. And it makes sense since “neutral” is the default value. But Windows XP and Windows Server 2003 don’t work that way. So lesson learned: ALWAYS make sure that the assemblyidentity element in the client manifest matches the embedded manifest in the dependent assembly. And if you get an error that a dependent assembly could not be found, make sure that the language attributes match. And always test your solution on all operating systems that you claim to supportJ.

Hopefully next posts will be about lesson learned from doing real solutions architecture work and not from chasing mismatched attributes in manifest filesJ.

Grzegorz Gogolowicz

Senior Solutions Architect

GISV Architecture Team

The ISV was aware of ClickOnce; however they assumed that ClickOnce couldn’t solve their problems, because of the following preconceptions:

-          they thought that ClickOnce couldn’t help with deployment of unmanaged applications

-          their applications uses COM components implemented in .NET and they thought that ClickOnce couldn’t help with deployment of COM components, because they thought that in order to deploy COM components users would have to have admin rights, be able to write to Windows Registry and be able to upload files to GAC. 

I clarified these misconceptions and stated that it should be possible to use ClickOnce to deploy Delphi apps with COM components implemented in .NET and that it should work even for users with no admin rights and it wouldn’t require updating Registry or placing assemblies in GAC.

Individual pieces of this concept are documented; however, I couldn’t find any end-to-end solution addressing all the requirements of this ISV, so I created a sample proof of concept demonstrating the end to end scenario and wanted to share it in case someone else will find it useful as well.  The source code of the sample is available at MSDN Code Gallery.

My idea leverages a mechanism called registration-free activation of COM components, which is available on Windows XP SP2 and newer versions of Windows. This piece of my solution is quite well documented at MSDN and for instance there is a nice walkthrough available here.

One of the most important steps is to write a manifest for the managed assembly that exposes COM components. The manifest can be very simple – in my sample it looks like that:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity

      name="AssemblyWithComComponents"

      version="1.0.0.0"

      processorArchitecture="MSIL" />

  <clrClass

      clsid="{F1D4EF3D-7E94-4F45-887F-7CA3E76021A3}"

      progid="DemoNamespaceProgId.DemoNamespaceProgId"

      threadingModel="Both"

      name="DemoNamespace.DemoComponent"

      runtimeVersion="v2.0.50727">

  </clrClass>

  <file name="AssemblyWithComComponents.dll">

  </file>

</assembly>

The next step is to embed this manifest as a RT_MANIFEST unmanaged resource directly into the assembly dll. In Visual Studio 2008 it can be done as easily as by creating a one line rc file:

1 24 AssemblyWithComComponents.manifest

and setting its Build Action to “Resource” in the Solution Explorer.

The last key step is to create a manifest file for the client application (e.g., your Delphi app or a VB6 app as in my sample). In my sample this is as simple as this:

<?xml version="1.0" encoding="utf-8"?>

<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:dsig="https://www.w3.org/2000/09/xmldsig#" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">

  <assemblyIdentity version="1.0.0.0" name="Client.exe"/>

  <dependency>

    <dependentAssembly >

      <assemblyIdentity name="AssemblyWithComComponents" version="1.0.0.0" processorArchitecture="MSIL" />

    </dependentAssembly>

  </dependency>

</asmv1:assembly>

By having these manifest files we can use registration-free activation of COM components - in our case a COM component implemented in a managed assembly.

When the following components: the client application, the client manifest file and the assembly dll with the embedded manifest are deployed together (for instance using ClickOnce with a help of a managed launcher application as in my sample) we achieve the goal of exposing COM components implemented in managed code without putting the assemblies into GAC, and without touching Registry and without having admin rights.

The zip file that I uploaded to MSDN Code Gallery contains the full source code of my sample and all ClickOnce deployment files. The sample consists of:

-          AssemblyWithComComponents project – a .NET assembly (implemented in C#) that implements a COM component,

-          Client project - unmanaged client applications (in my sample it is a VB6 app, but it could be also a Delphi app or other unmanaged app) that use the above COM component,

-          ClientLauncher project – a tiny managed app (implemented in C#) that simply launches the proper client application (Client.exe) and its role is to allow deploying the whole solution through ClickOnce

-          Publish folder for ClickOnce deployment. Setup.exe from that folder can be run without admin rights and it will deploy the application using ClickOnce and then launch the client app which in turn can call a method from the COM component.

Please note that if you want to recompile the sample, in particular the unmanaged Client project, you may need first to temporarily set the “Register for COM Interop” setting in AssemblyWithComComponents project settings. Just make sure to unregister the assembly if you want to test the registration-free activation. 

The minimum requirement to leverage this approach is Windows XP SP2 or Windows Vista.

I tested it on Windows Vista SP1, Windows Server 2003 SP2 and Windows XP SP2.

When working on solution architecture with global ISVs we often help them by connecting the dots between various technologies, often by drawing boxes and lines. Sometimes we get our hands dirty and we connect the dots by writing samples that demonstrate end to end scenarios leveraging existing technologies, as in this case.

Hope you will find this sample useful,

Grzegorz Gogolowicz

Senior Solutions Architect

GISV Architecture Team