As with all programming tasks, there are many different ways to create a program that solves the problem. The trick is, as ever, to write the program, get it working, and then optimise it. It may be that after you have your program up and running (and profiled), you’ll discover that there are some places that you’ve used LINQ which would be better off using stored procedures running within your database or vice versa or using LINQ to access stored procedures. The trouble is that whether LINQ is the best approach for your applications is something that you’ll find out only after you’ve worked with it for a while. What is sure though is that the advantages of using LINQ are so tremendous that it cries out for a code now, optimise later approach.
Just a quick note on the new Browser History feature in .NET 3.5 SP1. I had some time to experiment with beta 1. Because of its long gestation period as part of the ASP Futures package, it has been written about a lot. However, as is the curse of beta software, there is a ‘breaking change’ between the beta 1 release and the futures package version that many blog articles write about.
The feature is still enabled using the EnableHistory attribute on your page’s ScriptManager object.
<asp:ScriptManager runat="server" id="sm1" EnableHistory="true" />
However, the EnableStateHash attribute which you can use to have ASP.NET encrypt or not encrypt the page state in its querystring has been renamed. It is now called EnableSecureHistoryState.
via ADO.NET Team Blog
It’s settled! The Entity Framework (and the Entity Designer) along with ADO.NET Data Services will RTM as part of the Visual Studio 2008 and .NET 3.5 SP1 releases!
Unfortunately, we don’t have official release dates at this point, but stay tuned. You’ll also want to keep an eye out for the upcoming SP1 Beta 1, which will be your next chance to check out updated bits for both of these products.
Elisa Flasko
Program Manager, Data Programmability
It has taken a few years but Microsoft has announced that it will make the source code for the majority of its .NET framework libraries available for download with the release of Visual Studio 2008 and .NET 3.5 later this year.
Initially the release will include the source code (with source file comments included) for the .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), and WPF (System.Windows). Source code for more libraries such as WCF, Workflow, and LINQ will be added in later releases. The source code will be released under the Microsoft Reference License (MS-RL), which in a nutshell says “You can look at this, but don’t change anything”.
The full announcement from Scott Guthrie can be found on his blog here. From a developer’s point of view, this can only be good. Rather than relying on newsgroups for those buggy itches that can’t be scratched, developers should now be able to use the source code to trace exactly why their problems are occurring and make changes accordingly. Of course, by releasing the source code, the b0rg will open themselves up to criticism from some for their actual coding. Indeed, the first such comment from the ‘not my code, I could write better’ camp has already been posted based on the contents of the screenshots in Scott’s post.
As agilists and design pattern specialists ready their knives and posts for their release, it’s worth remembering that this is a huge step for Microsoft. Read only or not, for them to start opening up their code takes a lot of guts. Reactions from the open source world and podcasts are already appearing in reaction to the announcement.
So I tried to install VS2008 b2 on my work laptop this morning and got a shower of red fail icons while .NET 3.5 while being installed. All the log files for this install are in the %temp% directory, so i had a look there. And in the log dd_dotnetfx35error.txt, the less than useful line:
Microsoft .NET Framework 3.0a: [2] Error: Installation failed for component Microsoft .NET Framework 3.0a. MSI returned error code 1603
1603 is just the code for a fatal error, so that's not much use. The problem is with the .NET 3.0 install, so I had a look in dd_NET_Framework30_Setup6CEB.txt. Sure enough, a handful of 1603 errors looking mostly like this.
MSI (s) (88:70) [11:25:20:186]: Product: Microsoft .NET Framework 3.0 Service Pack 1 - Update 'WPF_Other_32' could not be installed. Error code 1603. Additional information is available in the log file C:\DOCUME~1\dmaharry\LOCALS~1\Temp\dd_NET_Framework30_Setup6CEB.txt.
But no additional information that I could find. Mooching around online for a few more clues, I found two great posts from Aaron Stebner on getting to the heart of 1603s (or slightly further towards it anyway)
The gist of the posts is that you can add a couple of flags to the registry that tell Windows Installer to log every single action it takes during an install. You can then look further into exactly what caused the issue and take action (hopefully). These are very large files though and take a while to create - VS2008 creates a 12MB file in about an hour just to load the installer components and get to the first installer screen so it's not for someone in a rush.
In my case, the post-install after .NET 3.0 SP1 wasn't working so the whole thing crashed. I ran it separately from the \wcu\dotNetFramework\dotNetFX30\NetFX30a_x86.msi file on the DVD identified in dd_NET_Framework30_Setup6CEB.txt as the cause of the problem and it worked fine. VS2008 then installed fine. YMMV, but Adrian Roman details his adventures with the same process here so you can see the kind of detail made available with Aaron's tip.