Useful tidbit:

“Editing Files in a WSP

Sometimes you don’t have the Visual Studio project handy for a wsp—but you want to change something (settings, etc). I can remember trying this a while back and finding it tedious—having to resort to makecab and the like. The need came up again so I figured it was worth a search to see if anything had changed, and behold, there is an easier way now. Thanks to Grumpy Wookie for posting about a nice archiving utility, IZArc, and how to use it to edit wsp’s. I found a slightly simpler process. The steps are basically:

• Rename the WSP to CAB
• Extract the wsp to a folder
• Edit the extracted files as needed
• Select all the files in extracted folder (Ctrl-A) and create a zip archive (this avoids the problem Grumpy Wookie ran into with IZArc not handling subfolders)
• Open the zip in IZArc and do Tools > Convert Archive and select Cabinet (.cab) as the Output Type to create it as a CAB
• Edit the created cab file to change it back to a wsp

You can download IZArc from CNet.”

Those .Net DLLs you have are compiled into something called byte-code (aka MSIL).  This is kind of like a more machine readable version of your code, but it can’t be run directly by your computer.

Instead, there’s a program (referred to as a virtual machine and in .net, it’s the .Net CLR) that compiles this bytecode dll into a native image format (this is called just in time compiling aka JITing).

Why does all of this matter to us? Well, if you’re using reflector & trying to debug some cod ewhere you don’t have any source code, you may find it precompile a non-optimized version of the bytecode dll.

You can do this with NGEN (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=VS.100).aspx) and by defining these flags in the .ini config file

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

Just noticed the documentation was incorrect for the RCDC in FIM.  Here’s what it hsould be 

Making regular expressions case insensitive

In FIM 2010, it can be helpful to make some regular expressions case insensitive. You can ignore case within a group by using ?!:. For example, for Employee Type, use the following:

^(?i:contractor|full time employee)$

The incorrect version was ^(?!:contractor|full time employee)%

I thought I posted the follow up but must’ve got sidetracked.

Scenario:
User John does an update request on John.Manager => launches authorization workflow, which uses the public client to create a request to the middle tier on John’s behalf?

If you enable delegation on your public proxy WCF bindings, you can in your activities impersonate the user credentials with this call:
(actually, you may only need to be impersonation since you’re impersonated call never leaves the box to talk to the fim service)

ServiceSecurityContext.Current.WindowsIdentity.Impersonate();

Then, if you use the public client in your code to make calls to the fim service, you will be under that user’s credentials and can kick off other necessary MPRs.

Couple of salient points:

1. All code that follows that impersonation call will be under the users credentials. Makes sense right? So what happens if you have a create activity or an update activity in your workflow? It fails b/c that thread is under the user context so any connections to the sql fim store to run any sprocs will fail b/c that user doesn’t have access to the DB.

2. ServiceSecurityContext is backed by a [ThreadStatic] attribute. ThreadStatic means an variable is scoped only to the current thread. Which means if you fork a new thread, that context is lost. So why does this matter to us? Well, when workflows passivate or get persisted to the DB (ex: when an activity is waiting on input from an approver), that context gets lost. So when your code comes back up, you no longer have access to ServiceSecurityContext.

3. If you’re under the impersonated context when the workflow passivates….wild things may happen. Haven’t tested it.

4. You no longer have parenting of requests. There are no longer chains of requests so if you cancel a parent request, the new request you spawned may

5. You have to handle the logic of how to wait on the new request you just spawned: does your activity proceed if there’s an authz workflow kicked off? Does it wait on the input? What if there’s an authn workflow? Does it handle the child requests interactive action workflows? Yup, it’s very nasty and hairy to solve in the general case (there is a reason why the FIM team doesn’t have this enabled by default)

Here’s what I would suggest (haven’t had time to fully explore this, just used this to implement delegation as a proof of concept):

1. Store the WindowsIdentity locally when overriding OnActivityExecutionLoad

2. Have very simple defined cases of when you kick off requests that spawn new AuthZ workflows. Don’t try to solve the general case. Any case that requires chainign of requests => pain

3. Keep the impersonation scope very limited and defined:

using(ServiceSecurityContext.Current.WindowsIdentity.Impersonate())

{

//Code to call public client to talk to FIM service

}//Impersonation is always reverted this way

4. For auditing/reporting, the child request that gets created this way will have the user as the actorID. Just be aware.

int[] arr={0}; int value = arr[arr[0]++]; Value = ?

.NET Reentrancy and Locking

The locking mechanism of the common language runtime (CLR) doesn’t behave exactly as one might imagine; one might expect a thread to cease operation completely when requesting a lock. In actuality, the thread continues to receive and process high-priority messages. This helps prevent deadlocks and make interfaces minimally responsive, but it introduces the possibility for subtle bugs.  The vast majority of the time you don’t need to know anything about this, but under rare circumstances (usually involving Win32 window messages or COM STA components) this can be worth knowing.

How It Relates to WPF

Most interfaces are not built with thread safety in mind because developers work under the assumption that a UI is never accessed by more than one thread. In this case, that single thread may make environmental changes at unexpected times, causing those ill effects that the DispatcherObject mutual exclusion mechanism is supposed to solve. Consider the following pseudocode:

Most of the time that’s the right thing, but there are times in WPF where such unexpected reentrancy can really cause problems. So, at certain key times, WPF calls DisableProcessing, which changes the lock instruction for that thread to use the WPF reentrancy-free lock, instead of the usual CLR lock. 

So why did the CLR team choose this behavior? It had to do with COM STA objects and the finalization thread. When an object is garbage collected, its Finalize method is run on the dedicated finalizer thread, not the UI thread. And therein lies the problem, because a COM STA object that was created on the UI thread can only be disposed on the UI thread. The CLR does the equivalent of a BeginInvoke (in this case using Win32’s SendMessage). But if the UI thread is busy, the finalizer thread is stalled and the COM STA object can’t be disposed, which creates a serious memory leak. So the CLR team made the tough call to make locks work the way they do.  

The task for WPF is to avoid unexpected reentrancy without reintroducing the memory leak, which is why we don’t block reentrancy everywhere.

5 years later and I still can’t keep all the MIIS Terms straight.  I always end up hunting for this graphic:

First, let it be known that I hate xml config files.  It’s a pain in the ass to write a script to modify certain portions of it…like when I want to turn off or turn on tracing in the FIM portal or the RMS.  So I usually resort it to doing it by hand….which is terrible because I always forget small details.

Like why is message logging not happening? Oh yeah.  Have to add this tag:

<system.serviceModel>

    <diagnostics wmiProviderEnabled=”true”>

        <messageLogging 

             logEntireMessage=”true” 

             logMalformedMessages=”true”

             logMessagesAtServiceLevel=”true” 

             logMessagesAtTransportLevel=”true”

             maxMessagesToLog=”3000” 

         />

    </diagnostics>

    <behaviors>

       <serviceBehaviors>

          <behavior name=”Default”>

             <serviceDebug includeExceptionDetailInFaults=”true”/>

            </behavior>

        </serviceBehaviors>

    </behaviors>

  </system.serviceModel>

  <system.diagnostics> 

    <sources> 

      <source name=”System.ServiceModel.MessageLogging” switchValue=”Verbose,ActivityTracing”> 

        <listeners> 

          <add type=”System.Diagnostics.DefaultTraceListener” name=”Default”> 

            <filter type=”” /> 

          </add>

          <add name=”DiagnosticListener”> 

            <filter type=”” /> 

          </add> 

        </listeners> 

      </source> 

      <source name=”System.ServiceModel” switchValue=”Information,ActivityTracing” propagateActivity=”true”> 

        <listeners> 

          <add type=”System.Diagnostics.DefaultTraceListener” name=”Default”> 

            <filter type=”” /> 

          </add> 

          <add name=”DiagnosticListener”> 

            <filter type=”” /> 

          </add> 

        </listeners> 

      </source>

      <source name=”Microsoft.ResourceManagement” switchValue=”Verbose,ActivityTracing” propagateActivity=”true”>

        <listeners>

          <add type=”System.Diagnostics.DefaultTraceListener” name=”Default”>

            <filter type=”” />

          </add>

          <add name=”DiagnosticListener”>

            <filter type=”” />

          </add>

        </listeners>

      </source>

    </sources> 

    <sharedListeners>

      <add initializeData=”C:\logs\FIMPortal.Client_tracelog.svclog” type=”System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”

        name=”DiagnosticListener” traceOutputOptions=”LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack”>

        <filter type=”” />

      </add>

    </sharedListeners> 

    <trace autoflush=”true” />  

  </system.diagnostics>