BitCrazed
Exploring the wonderful world of technology and software development   RSS 2.0
Archive
<August 2008>
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456
Sponsors
Disclaimer
THE OPINIONS EXPRESSED
HEREIN ARE MY OWN AND DO NOT
NECESSARILY REPRESENT MY
EMPLOYER'S VIEWS.

© Copyright 2008 Richard Turner

Sign In
Statistics
Total Posts: 16
This Year: 11
This Month: 0
This Week: 0
Comments: 7
 Thursday, January 17, 2008
.NET Framework Library Source Code now available - ScottGu's Blog

Scott has just announced that the .NET Framework Library Source Code now available!! As Scott states: You can now browse and debug the source code for the following .NET Framework libraries:

  • .NET Base Class Libraries (including System, System.CodeDom, System.Collections, System.ComponentModel, System.Diagnostics, System.Drawing, System.Globalization, System.IO, System.Net, System.Reflection, System.Runtime, System.Security, System.Text, System.Threading, etc).
  • ASP.NET (System.Web, System.Web.Extensions)
  • Windows Forms (System.Windows.Forms)
  • Windows Presentation Foundation (System.Windows)
  • ADO.NET and XML (System.Data and System.Xml)

We are in the process of adding additional framework libraries (including LINQ, WCF and Workflow) to the above list.

Note: The primary goal here is to enable developers to view source code to the underlying .NET Framework while building apps. As such, the ability to view the source to .NET is granted under a read-only reference license.

Happy hacking! :)

Posted: Thursday, January 17, 2008 12:22:11 AM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.NET | Development

 Thursday, November 01, 2007
Running .NET EXE's from network shares by default? Just say No!

Brad Abrams is asking whether or not the default behavior of the .NET runtime should allow your machine to run .NET applications stored on network shares by default.

Today, you can run native EXE's stored on a network shares without having to do any security work at the desktop. .NET application on the other hand will fail with a somewhat unhelpful "[exename] has encountered a problem and needs to close.  We are sorry for the inconvenience" error message.

This is, as Brad points out, a well known issue with some simple workarounds involving:

  1. Configuring your machine to trust a given strong-named (i.e. signed) .NET EXE (using MSCORCFG.MSC; details here)
  2. Alter your machine's Code Access Security Policy to trust a given network share (using CASPOL.EXE, as shown by Shawn)

I believe that softening the default Code Access Policy to permit .NET EXE's to run from default shares will introduce too many opportunities for malicious software authors to fool users into running apps that they think they trust.

Remember the ILoveYou virus which, as Dominick points out, copied itself to network shares as one of the avenues through which it spread its infection?

The only way I could accept such a sweeping change is if only EXE's that are Digitally Signed with a cert from a Certificate Authority in my trusted root store were permitted to run from a network share. Otherwise users WILL be fooled into running something that is less than desirable and which causes significant damage ... something I think we should all take steps to avoid.

In short, Just say NO!

Posted: Thursday, November 01, 2007 4:51:45 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.NET | Security

 Wednesday, October 03, 2007
Releasing the Source Code for the .NET Framework Libraries - ScottGu's Blog

image The wait is over and the prayers of many have been answered! From Scott Guthrie's blog this morning:

Today I'm excited to announce that we'll be providing [the source code to major parts of the .NET Framework] with the .NET 3.5 and VS 2008 release later this year.

[Source: Releasing the Source Code for the .NET Framework Libraries - ScottGu's Blog]

I know that this news is going to make a lot of people VERY happy indeed. :)

There is much debate about whether open or shared-source projects truly deliver enough benefit versus the cost of potentially giving away the crown jewels. However, I think it safe to say that it's generally universally accepted that it's a heck of a lot easier to successfully build apps and systems on top of a framework if you're able to peer down into the framework to see what's going on inside.

Remember the old days when we used to write apps on top of Borland's TurboVision, OWL and Visual Component Library or Microsoft's MFC and ATL? It was immensely useful to be able to single-step down into the framework in many cases.

Whilst we published portions of the BCL in the Shared Source CLI (I highly recommend the SSCLI/Rotor book to better understand what's going on in the CLR itself), you now get to delve around within a significant superset of the .NET Framework library's source code:

  • .NET Base Class Libraries
    • System, System.IO
    • System.Collections
    • System.Configuration
    • System.Threading
    • System.Net
    • System.Security
    • System.Runtime
    • System.Text,
    • etc...
  • ASP.NET
    • System.Web
  • Windows Forms
    • System.Windows.Forms
  • ADO.NET
    • System.Data
  • XML
    • System.Xml
  • WPF
    • System.Windows

Keep your eyes peeled for follow-up details of this news :)

Posted: Wednesday, October 03, 2007 10:16:24 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.NET

All content (unless otherwise specified) is © Copyright 2008 Richard Turner.