MSDN error on VS2003 while running as non-admin

I've recently dropped my main XP user down to the "average schmo" level like I should (and like I have in my primary development VirtualPC image.) When I tried to pull up the help on anything the installation wizard for VS2003 would pop up, eventually failing with this error:

Error 1606.Could not access network location wwwroot$: Unable to get security info for this object.

In case anyone else has this problem, here's how you fix it (verbatim from Felix Wang):

Log on with the Admin user.

Rename the following file:

C:\Program Files\Common Files\Microsoft Shared\Office10\mso.dll

Launch VS.Net and let the reparation to finish.

Launch MSDN.

Close VS.Net and MSDN.

Search for the file named "CookDoc.dll". By default, it should be in
"C:\Program Files\Common Files\Microsoft Shared\MSDN".

Let's register the file by the following command:

RegSvr32 "C:\Program Files\Common Files\Microsoft Shared\MSDN\CookDoc.dll"

Logon with the original user.

Scooped from usenet on microsoft.public.vsnet.setup in this thread. In case this link doesn't work the original post is titled "VS.NET/MSDN Annoyance" on Mar 9, 2004.

[Listening to: Concrete Blonde - It's a Man's World]

CreateProcessAsUser

Any blog entry that includes usage instructions of use in rare circumstances and with caution deserves a link. K. Scott Allen's sample code / wrapper around CreateProcessAsUser

[Listening to: Iron Maiden - Caught Somewhere in Time]

Easily Creating a StrongNameMembershipCondition for an Assembly

Another gem from Shawn Farkas: Easily Creating a StrongNameMembershipCondition for an Assembly

[Listening to: Electric Light Orchestra - Turn to Stone]

Creating an AppDomain with limited permissions

Shawn Farkas has to be on my top 10 list of bloggers. His blog entries and snippets are awesome and (eerily enough) tend to be right along the lines of stuff that I'm going to need. How does he know what I'm doing? Hey Shawn, that isn't you hanging around in the bushes outside my office window is it?

Without further ado: Creating an AppDomain with limited permissions.

[Listening to: Eartha Kitt - Where is my man]

More Performance Tidbits for library writers

More Performance Tidbits for library writers from the performance guru Rico "measure first" Mariani.

At some point either they'll figure out a way to really profile in a VPC image or I'll have to knuckle under and install VS2005 on my host PC. 'Til then, my head is firmly in the sand.

[Listening to: Alice in Chains - Junkhead]

Getting the Current Permissions in a Named Permission Set

Shawn Farkas posted a snippet on Getting the Current Permissions in a Named Permission Set. I like snippets. Snippets are good. Long live snippets.

Does it make sense for me to define my own Named Permission Set for my service? Don't know yet. Haven't spent enough time looking.

[Listening to: Kittie - In Winter]

Programatically changing file permissions

I'm back to implementing some permission related unit tests that I balked at earlier.

It took me a bit of time to find how to remove all permissions from a file. Since I don't want to have to go through this again I'll post it here.

Basically I'm pulling what I found in Keith Brown's absolute must read wiki: The .NET Developer's Guide to Windows Security in How to program with SIDs into a class.

I implemented it in a typical Resource Acquisition Is Initialization manner using IDispose so that I know I'll restore the permissions to their original after my tests are done.

Here's the class (a little light on error checking for brevity):

class ApplySecuritySettingsToFile : IDisposable

{

    #region Private Members

    private FileSystemAccessRule m_AccessRule = null;

    private FileInfo m_FileInfo = null;

    #endregion

    


    #region Constructor

    public ApplySecuritySettingsToFile (string fileName,

        FileSystemAccessRule accessRule)

    {

        if (fileName == null && accessRule == null)

            return;

        


        m_FileInfo = new FileInfo (fileName);

        m_AccessRule = accessRule;

        


        FileSecurity sd = m_FileInfo.GetAccessControl ();

        sd.AddAccessRule (m_AccessRule);

        m_FileInfo.SetAccessControl (sd);

    }

    #endregion

    


    #region Dispose pattern

    private bool m_bIsDisposed = false;

    


    ~ApplySecuritySettingsToFile ()

    {

        Dispose ();

    }

    


    public void Dispose ()

    {

        if (!m_bIsDisposed)

        {

            if (m_FileInfo != null && m_AccessRule != null)

            {

                FileSecurity sd =

                    m_FileInfo.GetAccessControl ();

                sd.RemoveAccessRule (m_AccessRule);

                m_FileInfo.SetAccessControl (sd);

            }

            


            GC.SuppressFinalize (this);

            m_bIsDisposed = true;

        }

    }

    #endregion

}

And here's how you use it to Deny FullControl (i.e. remove all permissions) to file C:\temp\temp.txt for the BUILTIN\users group:

using (new ApplySecuritySettingsToFile (@"C:\temp\temp.txt",

    new FileSystemAccessRule (

        new SecurityIdentifier (

            WellKnownSidType.BuiltinUsersSid,

            null),

        FileSystemRights.FullControl,

        AccessControlType.Deny)

    )

)

{

    // You (and everyone else for that matter) now have

    // no permissions whatsoever to C:\temp\temp.txt

}

You could just as easily add permissions using AccessControlType.Allow.

Hope it helps.

[Listening to: Marilyn Manson - Mother Inferior Got Her Gunn]

Boost XmlSerializer usability and performance by using strongly-typed serializers

A short but sweet bit on how to Boost XmlSerializer usability and performance by using strongly-typed serializers from Daniel Cazzulino of Mvp.Xml fame.

[Listening to: Delerium featuring Sarah McLachLan - Silence]

Number Formatting in .NET

An overview of Number Formatting in .NET via Kit George of the BCL Team.

I too have spent far too much time looking for the right format string on MSDN. This is a step in the right direction.

[Listening to: Rage Against the Machine - The Ghost of Tom Joad]

Nifty VS2003 tips for breakpoints and the "Find" combo box

Roy Osherove shows a few really nifty tricks: Advanced debugging tips and stuff you never knew about the "Find" combo box

[Listening to: Faster Pussycat - Babylon]

Programmatic .NET ACL Definitions

Another awesome security related code tidbit from Michael Willers:
TaskDriven Working with ACLs on files.

I'm already subscribed to his feed, but I somehow managed to miss this gem when it came out fresh. Much thanks to Jeff Newsom from Thinking Out Loud for reposting the link that actually made it past my forehead.



[Listening to: Soundgarden - Pretty Noose]

Upcoming Changes to System.Xml in .NET Framework 2.0 Beta 2

Dare Obasanjo provides an overview on the upcoming changes to System.Xml in .NET Framework 2.0 Beta 2.

[Listening to: Collective Soul - All]

The Osherove.Interception framework

Roy Osherove presents his Osherove.Interception framework. I'm not entirely convinced of how I would use this (or even if I should) but it definetely deserves looking into despite his use of the word automagically. Ugh.

I had previously blogged about it here as it pertained to unit testing.

[Listening to: KoRn - Blind]

Another keeper from MbUnit: AssemblySetUp/TearDown

Now that I've installed the latest MbUnit from TestDriven.NET I can make use of the TestFixtureSetUp and TestFixtureTearDown support in MbUnit (+ Assembly Setup and TearDown).

This has greatly simplified my code. In each of my test fixtures I used to have to have a SetUp method which calls a static initializer from another class to initialize my log4net stuff:

public class MyTests

{

  [SetUp]

  public static void SetUp()

  {

    StaticInitializer.Initialize()

  }

  [Test]

  public voidSomeTest()

  {

    ...

  }

}



public static class StaticInitializer

{

  private static bool s_bIsInitialized = false;

  public static void Initialize()

  {

    if (!s_bIsInitialized)

    {

      log4net.Config.BasicConfigurator.Configure (...);

      s_bIsInitialized = true;

    }

  }

}

Now all I need is:

public class MyTests

{

  //No extra stuff at all

  [Test]

  public voidSomeTest()

  {

    ...

  }

}



[assembly: AssemblyCleanup (typeof (StaticInitializer))]

public static class StaticInitializer

{

  [SetUp]

  public static void Initialize()

  {

    log4net.Config.BasicConfigurator.Configure (...);

  }

}

The rest is handled for me.

Sooo much nicer.

Loading an assembly from a "working directory" at design time

Steve Maine may have just helped me out of a problem that I didn't even know I had yet: Loading an assembly from a "working directory" at design time. Since I plan to load user assemblies I would've fallen over this eventually. Now I'm prepared... Or at least I've lost my excuse of not being prepared.

[Listening to: Collective Soul - The World I Know]

An exercise in implementing a domain-driven design

Steve Maine runs through a set of articles (Part I, Part II and Part III) doing an exercise in DDD (Domain Driven Design).

Not sure if I'll jump on the bandwagon, but it looked interesting enough to persist here.

[Listening to: Limp Bizkit - 9 Teen 90 Nine]

VS2005 Export Template Wizard

Craig Skibo details the new VS2005 Export Template Wizard. This seems to be a great way to provide out-of-the-box wizards to allow customers to customize your app.

[Listening to: George Clinton - The Shagadelic Austin Powers]

Unofficial NUnit Extensibility Framework (MbUnit too)

Roy Osherove puts together another creepy cool unit testing extension to both NUnit and MbUnit.

Introducing: Unofficial NUnit Extensibility Framework - make your own test attributes easily!

First the automatic database rollback feature, now this. Too cool.

I echo Jonathan's sentiment: this belongs in TestDriven.NET

[Listening to: Stone Temple Pilots - Sin]