Windows

Singularity - C# OS Released on CodePlex

Matthew Podwysocki — Wed, 12 Mar 2008 00:03:26 GMT

Update: If you want the .iso I used for the VPC, check it out here on my SkyDrive.

During my research and posts about Design by Contract and Spec# and my interactions with folks from Microsoft Research, I came across Singularity OS, an operating system written in an offshoot language based upon C#. In that time, I realized that the Singularity team extended Spec# and the Design by Contract and static verification pieces of it into a new language called Sing#.

Fast forward to last Tuesday. Almost five years after the start of development, it has finally been released onto CodePlex as an open source non-commercial academic license and can be found here. After reading about it and talking with some Microsoft Research folks about it, I had to give it a shot. That's one of the things I love about working at Microsoft is the fact that I can interact with people like these on a periodic basis.

History of Singularity

During my long commute to and from work, I have the pleasure of listening to many podcasts. Although I like the ones in the .NET space with Hanselminutes and DotNetRocks, I also like to venture into the Ruby and outside community where I'm pretty comfortable as well. So, one of my absolute favorites is Software Engineering Radio for the serious talk and geeking about languages and architecture. Lo and behold, the latest episode, Episode 88, covers Singularity with Galen Hunt where he talks with Markus, the host about the history and features of the OS. I suggest you listen to that before we go any further. Also, a good overview can be found here in PDF format.

If you think about most operating systems we run today, the essence of what they are is dated back in the 1970s and C and Assembly based. Back in 2003, Galen and team started this effort to write an operating system in managed code. Over 90% of the system is written in a language called Sing# which is an extension of Spec# which I will get into shortly. But, Singularity consists of three major parts, Software Isolated Processes (SIPs), contract-based channels, and manifest-based programs.

SIPs are interesting parts of Singularity. They provide a sandbox as it were for program execution free from meddling from outside processes. This includes its own memory space, threads and so on. In fact, memory and threads cannot be shared from one SIP to the other, so the vectors for malicious code are cut way down.

Contract-Based Channels are another interesting aspect of Singularity. It's a built-in feature of the Sing# language which I will get to in the next section. In short, what it provides is a quick and verifiable way of communicating between processes with messages. To support this, the Spec# language had to be extended to support this.

Lastly, manifest based programs are interesting because it defines the code that runs within the SIP and its behaviors. In Singularity, there really is no such thing as Just In Time Compiling (JIT) as all code needs to be loaded into memory and statically verified before it can be executed, which is something a JIT cannot do. But on the other side of this, it makes dynamic languages and late binding impossible as well. So, to work around this, they devised a plan called Compile Time Reflection, so you know your dependencies beforehand and uses Dependency Injection in a way to inject the appropriate dependencies. Really slick stuff!

Sing#

Rustan Leino and others in Microsoft Research had already begun an effort called Spec# to provide Design by Contract features to the C# language and a static verifier to prove that code is in fact working as the contracts were written. Just a quick aside, we're going to be lucky enough to have Rustan at ALT.NET Open Spaces, Seattle to talk about it and Design by Contract (Shameless Plug). Anyhow, back to the topic at hand. Spec# didn't have enough for the static verification that needs to happen. So, instead, Sing# brings us Contract Based Channels for creating message declarations and a set of named protocol sets. Any communication that crosses processes must use contract based channels. These messages that it passes have declarations that state the number and types of arguments for each message and an optional message direction. Each state specifies the possible message sequences leading to other states in the state machine.

I just want to dig through some code to see exactly what that looks like:

    class DirectoryServiceWorker
    {
        private TRef<DirectoryServiceContract.Exp:Start> epRef;
        private DirNode! dirNode;

        private DirectoryServiceWorker(DirNode! dirNode,
                                      [Claims] DirectoryServiceContract.Exp:Start! i_ep)
            requires i_ep.InState(DirectoryServiceContract.Start.Value);
        {
            epRef = new TRef<DirectoryServiceContract.Exp:Start>(i_ep);
            this.dirNode = dirNode;
            base();
        }

If you notice from above, you can see some Spec# goodness in there including NonNull types using the ! keyword and also requires preconditions. It's pretty well written and a lot of fun to dig through. If you want to learn more about compilers and operating systems, now is the time to sift through the source code and get your geek hat on.

Building the Image

If you want to actually run Singularity, the team has provided as part of the zip file, a way to build the operating system. You'll simply need the following:

Windows Debugging Tools
.NET Framework 1.1
Virtual PC 2007
MSBuild

There is a really well documented PDF file that comes as part of the download to walk you through the build procedure step by step. Basically, you kick off an MSBuild process which builds the image and then you can mount an iso image to see the results.

I was able to get the results in about 10 minutes or so for the build process. Then again, if you're running Vista, you need to be sure to launch the configure.cmd as an elevated process in order to kick things off properly. That was the first hurdle. But once I got that going, the rest was easy. And I got a pretty cool result as well when I ran the VPC image. Look at the goodness:

I have played with it just yet all that much. I'm figuring what I can do with it next. But, that's part of my copious spare time which doesn't seem to exist much anymore.

Conclusion

I've done well with my learning plan this year to keeping to what is on my plan and not deviating from it. Luckily languages such as Spec# and Sing# still fall into that category. It's pretty fascinating stuff and great to get my hands on an operating system using managed code. It's pretty impressive from the things I've read and the code I've read. I'm only hoping that research projects such as this make a significant impact on future versions of Windows, let alone future versions of most operating systems. Until next time...

Visual Studio 2008, SQL Server 2008 & Windows Server 2008 Launch Event Coming to a City Near You!

Matthew Podwysocki — Mon, 14 Jan 2008 23:22:41 GMT

As noted today, you can now register for the Launch of Visual Studio 2008, SQL Server 2008 and Windows Server 2008. You can find the closest event to you from here. For all you DC folks like me, our event is March 25th and you can find that registration information here.

Here is the basic information:

Take a test drive
Come to an event and test drive Windows Server® 2008 operating system, Microsoft® SQL Server® 2008, and Microsoft Visual Studio® 2008.

Meet the experts
Enjoy hands-on labs, face-to-face Q&A sessions with software experts, and other opportunities to interact with development team members.

Bring the products home
Want more? To say thanks for taking part of this exciting launch, you’ll take home a promotional kit with versions of all three products.

I was fortunate to be a part of the Washington DC Vista launch last year, help some of my DP&E give their presentations and even help with "Meet the Experts", so it's a great time. I was just tired by the end of the day directing people where to register and where lunch was. The lines were amazing and just outside in the freezing cold. A good time was had by all!

Microsoft Free Tools - Best Practice Analyzer for ASP.NET

Matthew Podwysocki — Mon, 03 Jul 2006 16:19:00 GMT

Microsoft has released a new tool called Microsoft Best Practice Analyzer for ASP.NET. This tool scans the configuration of an ASP.NET 2.0 application. The tool can scan against three mainline scenarios (hosted environment, production environment, or development environment) and identify problematic configuration settings in the machine.config or web.config files associated with your ASP.NET application.

This tool is current in alpha right now and Microsoft is counting on your feedback on how to proceed with this tool. I found it's pretty helpful in the scenarios I've run so far. It is very easy to use and much like the Microsoft Security Baseline Analyzer that I put on all of my machines.

Below is a sample of the output from one of the test runs I did on a Virtual PC of mine.

So, give the tool and try and let them know what you think!

Microsoft Identity Integration Server (MIIS) Resources

Matthew Podwysocki — Fri, 23 Jun 2006 12:59:00 GMT

Well, I survived giving a presentation of some of the coding that you can do with MIIS last night at the MICSUG meeting. Overall, it was a great meeting and it was good to see some new faces there.

Joe Francis from Microsoft gave a presentation of the current functionality and future plans for MIIS. He also briefly went over other Identity solutions at Microsoft.

Paul Laudeman of TCSC presented a case study of an MIIS implementation which included some very valuable lessons learned, some high points and low points. His blog at codebetter.com is a good resource should you have any questions regarding MIIS. The presentation to the MICSUG is available here.

Anyhow, I thought I would share some additional resources I came across to help you with an MIIS solution:

Sites:

* MIIS Home Page at Microsoft

* MIIS Technical Reference

* MIIS Support Center (Technet)

* MIIS Public User Group

* MIIS Design and Planning Collection

* MIIS Alliance

* MIIS Experts

Labs:

* Microsoft Identity Integration Server 2003 Virtual Lab

Newsgroups:

* MIIS Newsgroup

Blogs:

* Paul Laudeman

* Alex Tcherniakhovski

* Kim Cameron's Identity Blog

* Craig Martin - Identity Trench

* Paul's Digital Lounge and Cigar Bar

I hope that's a good starting point to get you familiar with what this product can do.

Day 10 of the Background Intelligent Transfer Service (BITS) Managed Wrapper

Matthew Podwysocki — Mon, 19 Jun 2006 00:05:00 GMT

Update: Put a comment in if you want the C# version of this code and I will get it to you

In the previous installment, I actually gave the source code which is available if you go to the Day 9 post. Anyhow, what we're going to cover today is setting up your IIS to allow for BITS upload functionality. Several things must be done in order for uploads to be supported on your machine.

First, we need to install the BITS Extensions for IIS. In order to do so, you must do the following:

Go to Add/Remove Programs from the Control Panel
From the Add/Remove Programs and click on the Add/Remove Windows Components item on the left menu
Click on Application Server and click Details
Click on Internet Information Services (IIS) and click Details
Check the Background Intelligent Transfer Service (BITS) Server Extensions and click OK.
Make sure you have the Windows CD available in case it needs and, and most likely it will.

Step 5 should look like this:

Now that we got that installed, let's go and create a virtual directory in IIS for the upload location. Go ahead and create your virtual directory much as you would for any other. This virtual directory does not require Write capability, as BITS takes care of that for you, so it is best to turn it off. If you are allowing anonymous access, the anonymous web user must have change permissions on that physical folder.

Once you do have set up the virtual directory, right click on it and go to Properties. You will now notice a BITS Server Extension tab. Below is a screenshot of what it looks like:

As you can see, we can override some of the settings which includes notifications, size limits, deleting incomplete jobs, etc. Most of the time, we really don't need to touch those values.

In the next post in this series, I'll do a simple program on how to upload a file to my local IIS instance.

Why Vista Slipped

Matthew Podwysocki — Fri, 16 Jun 2006 01:17:00 GMT

Phillip Su of Microsoft posted a great rant called Broken Windows Theory about why Microsoft Vista shipment date slipped. It's a very heated topic that caught the attention of Robert Scoble on his blog. Lately, Vista's dates have kept slipping and people have started to notice.

In there, he named the usual suspects of why Windows shipments are delayed, such as:

* Windows code is too complicated

* Windows has gone thermonuclear when it comes to process

He also claims that it is cultured to slip and that there are too many cooks in the kitchen. I think that he is pretty much pointing out the same problems most large organizations have when putting out a large product, at least in my experience. Interesting read to say the least.

Day 9 of the Background Intelligent Transfer Service (BITS) Managed Wrapper

Matthew Podwysocki — Thu, 08 Jun 2006 19:34:00 GMT

Update: Put a comment in if you want the C# version of this code and I will get it to you

Well, I was having troubles connecting to CVS on my Managed BITS Sourceforge Project over my VPC, so while I figure it out, I decided to upload the source code plus binaries to SaveFile for the time being. Let me know if you have any questions or problems regarding this.

Now that I got that out of the way, let's get back to where we left off. In the previous lesson, we talked about implementing the IBackgroundCopyCallback interface. Since this interface also implements IUnknown, we must also address that as well. I implemented the interface in a class called UnmanagedEventManager.

Let's take a look at the IUnknown interface implementation first.

// Query interface method
HRESULT Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::UnmanagedEventManager::QueryInterface(REFIID riid, LPVOID *ppvObj)
{
     // Check if IUnknown and IBackgroundCopyCallback
     if (riid == __uuidof(IUnknown) || riid == __uuidof(IBackgroundCopyCallback))
    {
         *ppvObj = this;
    } // if - riid
    else
   {
        *ppvObj = NULL;
        return E_NOINTERFACE;
   } // else - riid

   // Add reference
   AddRef();

return NOERROR;
} // method - UnmanagedEventManager::QueryInterface

// Add reference
ULONG Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::UnmanagedEventManager::AddRef()
{
return InterlockedIncrement(&m_lRefCount);
} // method - UnmanagedEventManager::AddRef

// Release
ULONG Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::UnmanagedEventManager::Release()
{
// Decrement count
ULONG ulCount = InterlockedDecrement(&m_lRefCount);

     // Delete if 0
     if(0 == ulCount)
          delete this;

return ulCount;
} // method - UnmanagedEventManager::Release

As you can see, we really did nothing special here. Just a standard plain-vanilla implementation of IUnknown. Now let's take a look at some of the methods that we must implement with the IBackgroundCopyCallback interface. We will note that the pCopyJobEventManager is of type gcroot<BackgroundCopyJobEventManager*>.

// Job error callback
HRESULT Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::UnmanagedEventManager::JobError(IBackgroundCopyJob __nogc* pJob, IBackgroundCopyError __nogc* pError)
{
// Call error event
pCopyJobEventManager->ErrorEvent(new BackgroundCopyJob(pJob), new BackgroundCopyError(pError));

return S_OK;
} // method - UnmanagedEventManager::JobError

// Job modification callback
HRESULT Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::UnmanagedEventManager::JobModification(IBackgroundCopyJob __nogc* pJob, DWORD dwReserved)
{
// Call modification event
pCopyJobEventManager->ModificationEvent(new BackgroundCopyJob(pJob));

return S_OK;
} // method - UnmanagedEventManager::JobModification

// Job transferred callback
HRESULT Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::UnmanagedEventManager::JobTransferred(IBackgroundCopyJob __nogc* pJob)
{
// Call transferred event
pCopyJobEventManager->TransferredEvent(new BackgroundCopyJob(pJob));

return S_OK;
} // method - UnmanagedEventManager::JobTransferred

Basically what these methods do is invoke the events when the IBackgroundCopyCallback is invoked from the IBackgroundCopyJob interface. You have the ability to set the IBackgroundCopyCallback interface implementation through the SetNotifyInterface and SetNotifyFlags methods. The event implementations are quite simple as well and that code follows:

// The error event
void Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::ErrorEvent(Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJob* pErroredJob, Podwysocki::Services::BackgroundTransferServices::BackgroundCopyError* pCopyError)
{
if(this->pJobModificationEvent != NULL)
this->pJobModificationEvent->Invoke(this, new BackgroundCopyErrorEventArgs(pCopyError, pErroredJob));
} // method - BackgroundCopyJobEventManager::ErrorEvent

// The modified event
void Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::ModificationEvent(Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJob* pModifiedJob)
{
if(this->pJobModificationEvent != 0)
this->pJobModificationEvent->Invoke(this, new BackgroundCopyJobEventArgs(pModifiedJob));
} // method - BackgroundCopyJobEventManager::ModificationEvent

// The transferred event
void Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJobEventManager::TransferredEvent(Podwysocki::Services::BackgroundTransferServices::BackgroundCopyJob* pTransferredJob)
{
if (this->pJobTransferredEvent != 0)
this->pJobTransferredEvent->Invoke(this, new BackgroundCopyJobEventArgs(pTransferredJob));
} // method - BackgroundCopyJobEventManager::TransferredEvent

It's important that we implement this class because we want a way to fire events upon completion of a job. As you can see, it's not entirely complex to translate the unmanaged code to managed, it just takes time and lines of code. Once again, the files are available from the link above, so let me know if you have any questions.

Day 8 of the Background Intelligent Transfer Service (BITS) Managed Wrapper

Matthew Podwysocki — Fri, 02 Jun 2006 15:44:00 GMT

Update: Put a comment in if you want the C# version of this code and I will get it to you

Well, I finally managed to get a spot for the Managed BITS Wrapper on SourceForge.net. I have not uploaded any files just yet, as I am cleaning up one or two things as well as trying to add some test cases to it. I will let people know when I actually have a release out there available. The first available release will be in Managed C++ and then the second release will be in C++/CLI.

I left off last time looking at some of the functions within the BackgroundCopyJob wrapper for IBackgroundCopyJob, IBackgroundCopyJob2, and IBackgroundCopyJob3. I haven't bothered with IBackgroundCopyJob4 since it is available only on Vista for the time being.

Where I would like to go today is to cover how we're going to wrap the NotifyInterface methods and the IBackgroundCopyCallback interface in order to perform events on job transferred, job error and job modification. This involves implementing a class with an unmanaged interface and wrapping it with a managed event manager.

Below is the definition of the BackgroundCopyJobEventManager: Note that it contains a lot of information to parse.

// This class encompasses NotifyInterface and the IBackgroundCopyCallBack
public __gc class BackgroundCopyJobEventManager : public System::IDisposable
{
public:
// Job error event handler
__delegate void JobErrorEventHandler(Object* sender, BackgroundCopyErrorEventArgs* e);

// Job modification event handler
__delegate void JobModificationEventHandler(Object* sender, BackgroundCopyJobEventArgs* e);

// Job transferred event handler
__delegate void JobTransferredEventHandler(Object* sender, BackgroundCopyJobEventArgs* e);

private:
     // Member variables
     JobErrorEventHandler* pJobErrorEvent;
     JobModificationEventHandler* pJobModificationEvent;
     JobTransferredEventHandler* pJobTransferredEvent;
     bool isDisposed;

     // Unmanaged event handler
     __nogc class UnmanagedEventManager : public IBackgroundCopyCallback
     {
     private:
          gcroot<BackgroundCopyJobEventManager*> pCopyJobEventManager;
          LONG m_lRefCount;

     public:
          // Constructor that takes a BackgroundCopyJobEventManager
          UnmanagedEventManager(gcroot<BackgroundCopyJobEventManager*> pCopyJobEventManager);

// Destructor
~UnmanagedEventManager() {}

          // IUnknown methods
          HRESULT __stdcall QueryInterface(REFIID riid, LPVOID *ppvObj);
          ULONG __stdcall AddRef();
          ULONG __stdcall Release();

// Job error callback
HRESULT __stdcall JobError(IBackgroundCopyJob* pJob, IBackgroundCopyError* pError);

// Job modification callback
HRESULT __stdcall JobModification(IBackgroundCopyJob* pJob, DWORD dwReserved);

// Job transferred callback
HRESULT __stdcall JobTransferred(IBackgroundCopyJob* pJob);

}; // class - UnmanagedEvents

UnmanagedEventManager __nogc* pUnmanagedEvents;

public:
// Public constructor
BackgroundCopyJobEventManager();

// Destructor
~BackgroundCopyJobEventManager();

// Dispose method
__sealed void Dispose();

// Add a job to monitor with default flags
void AddBackgroundCopyJob(BackgroundCopyJob* pMonitoredJob);

// Adds a job to monitor with the specified flags
void AddBackgroundCopyJob(BackgroundCopyJob* pMonitoredJob, BackgroundCopyJobNotifyFlags notifyFlags);

     // Copy error event handler
     __event virtual void add_JobErrorEvent(JobErrorEventHandler* value);
     __event virtual void remove_JobErrorEvent(JobErrorEventHandler* value);

     // Job modification event handler
     __event virtual void add_JobModification(JobModificationEventHandler* value);
     __event virtual void remove_JobModification(JobModificationEventHandler* value);

     // Job transferred event handler
     __event virtual void add_JobTransferred(JobTransferredEventHandler* value);
     __event virtual void remove_JobTransferred(JobTransferredEventHandler* value);

public private:
// The error event
void ErrorEvent(BackgroundCopyJob* pErroredJob, BackgroundCopyError* pCopyError);

// The modified event
void ModificationEvent(BackgroundCopyJob* pModifiedJob);

// The transferred event
void TransferredEvent(BackgroundCopyJob* pTransferredJob);

protected:
// Overloaded dispose method
virtual void Dispose(bool disposing);

}; // class - BackgroundCopyJobEventManager

So, let's cover this little by little. We have an inner class called UnmanagedEvents which wraps the functionality in the IBackgroundCopyCallback. As you can see, we also need to implement the IUnknown interface, as the IBackgroundCopyCallback does. If you will also notice, I used the gcroot template which allows us to create managed types within unmanaged classes.

Since this is an unmanaged class, we must implement a destructor to clean up the code in the BackgroundCopyJobEventManager. To save some time, I also implement the IDisposable interface as well so that cleanup can happen more quickly than waiting for the garbage collector to hit the destructor.

As you also notice, we have three event types, one for Transferred Events which occur when the job state is Transferred, one for Modified Events which occur when a job has been modified in any way, and one for Error Events which occur when there is an error associated with the BackgroundCopyJob.

That's it for today, but stay tuned for more.

Day 6 of the Background Intelligent Transfer Service (BITS) Managed Wrapper

Matthew Podwysocki — Wed, 24 May 2006 22:47:00 GMT

UPDATE: See Day 9 of the Background Intelligent Transfer Service (BITS) Managed Wrapper for the source code plus binaries.

In previous lessons, I covered the BackgroundCopyManager and how I wrapped the IBackgroundCopyManager in Managed C++. Today, I'll go a step further to look at the BackgroundCopyJob wrapped class.

The BackgroundCopyJob wraps the following interfaces:

* IBackgroundCopyJob

* IBackgroundCopyJob2

* IBackgroundCopyJob3

As we are dealing with unmanaged types, we must also take into consideration of implementing the System.IDisposable interface. Let's go over the basic layout of the IDisposable pattern:

public:

void Dispose();

protected:

virtual void Dispose(bool disposing);

private:

bool isDisposed;

Now that we got that out of the way, let's go over the methods and properties we will be implementing. Let's go over the public properties first:

// Gets or sets the ACL tags
__property BackgroundCopyJobFileACLFlags get_ACLTags();
__property void set_ACLTags(BackgroundCopyJobFileACLFlags value);

// Gets the creation time
__property DateTime get_CreationTime();

// Gets and sets the description
__property String* get_Description();
__property void set_Description(String* value);

// Gets and sets the display name
__property String* get_DisplayName();
__property void set_DisplayName(String* value);

// Gets the error for the job
__property BackgroundCopyError* get_Error();

// Gets the error count
__property System::Int64 get_ErrorCount();

// Gets the BackgroundCopyFiles
__property BackgroundCopyFileCollection* get_Files();

// Gets the ID
__property Guid get_Id();

// Gets and sets the minimum retry delay
__property System::Int64 get_MinimumRetryDelay();
__property void set_MinimumRetryDelay(System::Int64 value);

// Gets the modification time
__property DateTime get_ModificationTime();

// Gets and sets the no progress timeout
__property System::Int64 get_NoProgressTimeout();
__property void set_NoProgressTimeout(System::Int64 value);

// Gets or sets the notify command line
__property NotifyCommandLine get_NotifyCmdLine();
__property void set_NotifyCmdLine(NotifyCommandLine value);

// Gets the owner
__property String* get_OwnerId();

// Gets the owner name
__property String* get_OwnerName();

// Gets and sets the priority
__property BackgroundCopyJobPriority get_Priority();
__property void set_Priority(BackgroundCopyJobPriority value);

// Gets the progress
__property BackgroundCopyJobProgress get_Progress();

// Gets and sets the proxy settings
__property BackgroundCopyJobProxySettings get_ProxySettings();
__property void set_ProxySettings(BackgroundCopyJobProxySettings value);

// Gets an in-memory copy of the reply data from the server application
__property MemoryStream* get_ReplyData();

// Gets or sets the name of the file that contains the reply data from the server application.
__property String* get_ReplyFileName();
__property void set_ReplyFileName(String* value);

// Gets the progress information related to the transfer of the reply data from an upload-reply job
__property BackgroundCopyJobReplyProgress get_ReplyProgress();

// Gets the background copy job state
__property BackgroundCopyJobState get_State();

// Get transfer completion time
__property DateTime get_TransferCompletionTime();

// Gets the job type
__property BackgroundCopyJobType get_Type();

And after all that, we still have the methods to review. Luckily, there are not as many methods as properties. So, let's review those now:

// Adds a file to the copy job
void AddFile(String* remoteUrl, String* localName);

// Adds a set of files to the copy job
void AddFileSet(BackgroundCopyFileInfo fileInfo[]);

// Add a file to a download job and specify the ranges of the file to download
void AddFileWithRanges(String* remoteUrl, String* localName, BackgroundCopyFileRange ranges[]);

// Cancels the job
void Cancel();

// Completes the job
void Complete();

// Dispose method
__sealed void Dispose();

// Removes credentials
void RemoveCredentials(AuthenticationTarget target, AuthenticationScheme scheme);

// Replace the beginning text of all remote names in the download job with the given string.
void ReplaceRemotePrefix(String* oldPrefix, String* newPrefix);

// Resume job
void Resume();

// Set credentials
void SetCredentials(String* userName, String* password, AuthenticationTarget target, AuthenticationScheme scheme);

// Suspend the job
void Suspend();

// Take ownership of job
void TakeOwnership();

So, as you can see, we have a ton of things to implement. It especially gets to be a lot of code to not only validate the incoming data (which is important), but translate the unmanaged types into managed ones. We'll go over some examples of that in another installment.

.NET Security - Exception Management

Matthew Podwysocki — Mon, 22 May 2006 15:10:00 GMT

In previous days, I talked about many other ways to write a secure application. Today I will cover exception management and handling as it pertains to application security.

When dealing with Exceptions, it's a best practice to hide the implementation details of your applications from the user. This includes hiding information regarding implementation, any secure data, and system configuration.

To provide a secure application with regards to exception handling:

* Use a structured exception handling routine

* Do not log potentially sensitive information

* Do not reveal implementation details or secure information to the user

* Consider an exception management framework

Use a structured exception handling routine

The .NET framework gives you the ability to do structured exception handling by using the try, catch and finally keywords. Place code that can fail inside try blocks and use the catch blocks to handle the exceptions. Inside the catch blocks, you may do additional logic such as logging. Use the finally block to clean up any resources such as SQL connections or IO readers even if the catch block was reached. Use exceptions instead of returning an integer much as you would with COM and C++ functions.

Below is an example of a good try-catch-finally block:

SqlConnection conn = null;

try

{

conn = new SqlConnection(myConnString);

conn.Open();

}

catch(SqlException se)

{

// Log Exception and do other handling

}

finally

{

if(conn != null) conn.Dispose();

}

Do not log potentially sensitive information

Exception messages and other exception details could reveal potentially sensitive information such as user passwords. When creating a logging policy for your organization, be conscious of what data will be logged and act accordingly. It can be a very fine line between not providing enough information to diagnose a problem and revealing too much information in the logs.

This could be an example of not logging sensitive information:

try

{

LoginUser(userName, password);

}

catch(SecurityException se)

{

// Log user name that failed, but not password

logger.LogEvent(string.Format(CultureInfo.CurrentCulture, "Access denied for user {0} at {1}", userName, DateTime.Now));

}

Do not reveal implementation details or secure information to the user

Another rule of thumb is to not show too much information to the user. It is a best practice to log the details of the exception and return a more friendly exception message back to the user. When using ASP.NET applications, it is best to use the <customErrors> element within the Web.config to show generic failures to the user.

The information that should not be displayed to the user include any of the following:

* Method names

* Machine names

* .NET framework version numbers

* SQL Statements

* Connection strings

* Other configuration items

Consider an exception management framework

In the enterprise architecture world, it is best to use an exception management framework. The Microsoft Patterns & Practices group released a best practices guide for exception handling here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp

The Microsoft Enterprise Library contains the Exception Handling Application Block which allows the implementer to create a strategy for exception handling throughout the enterprise.

The Exception Handling Application block allows the implementer to create a strategy in the following ways:

* Support exception handling in all layers instead of the service interface entry points

* Exception handling policies can be created and maintained at an administrative level

* It allows for easy wrapping of certain exceptions to hide the details while logging the exception

* It invokes exception handlers in a consistent fashion

More information about this block can be found at the link above and all of its functionality. As this blog continues, I will add more strategies for securing the enterprise application.