Silverlight Tips, Tricks and Best Practices

Here is a great MSDN article on some Silverlight tips, tricks, and best practices:  http://msdn.microsoft.com/msdnmag/issues/08/LA/WickedCode/default.aspx

View Full Article

ASP.NET Security Tutorials

Scott Mitchell, from 4GuysFromRolla.com, is writing a terrific tutorial series on ASP.NET Forms Authentication, Authorization, User Accounts, and Roles.  This is a great series of articles on the use of ASP.NET's built-in libraries to authenticate and identify visitors, lock down parts of your site through authorization, and manage users and roles.  When it's all finished, it is supposed to be a 14-part series or something like that.  Here is the link:

http://asp.net/learn/security/?lang=cs

View Full Article

Migrating from VS 2005 to 2008

So I just finished migrating a whole slew of our large solutions and projects from Visual Studio 2005 to Visual Studio 2008.  The conversion process itself was really simple and painless (and not too time consuming).  There were a few gotchas with our Setup (AKA Deployment) Projects however:

1. It appears that Microsoft moved the location of it's prerequisite packages for the BootStrapper for VS 2008.  Microsoft used to keep them at C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages, but now in 2008 it looks they have moved them to a more isolated and common location.  The new location is C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages.  When I converted our setup projects to VS 2008 format, some of the prerequisites couldn't be found because of this.  I just went to the old VS 2005 BootStrapper location and copied the folders of the packages I needed to the new VS 2008 location (for example, the MDAC package is under a folder called MDAC28, and it is not in VS 2008's list of packages by default anymore).
2. We had a folder structure into which we were dropping the Primary Output of a web application in our setup projects.  For a web application project, the Primary Output is the DLL libraries in the bin directory of the web site.  In VS 2005, you would create a bin folder at the root level of the web site and put the Primary Output down a level in the bin folder.  Well, now in VS 2008, it appears that wherever you put the Project Output, the setup project will create a bin folder at that location and put the DLL libraries in that bin folder one level down from where you put the Project Output.  So I had to go back through our setup projects and move the location of those Primary Outputs one level up (or else it would create a bin folder inside of the bin folder).

One nice thing about the migration to VS 2008 is that it looks like Microsoft has a new version of the Visual C++ Runtime Libraries prerequisite (I don't know if the libraries are actually any different, but at least the redistributable package and logic are improved).  We have a set of products that have this package as a prerequisite during install.  Every time you ran the installer it would reinstall the package.  It was almost as if it wasn't doing any logic to detect if it already had the package installed.  The following link might be the explanation of why we were seeing this odd behavior (even though it references the MDAC package):  http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=339044&SiteID=1

Well, the new Visual C++ Runtime Libraries package works great and doesn't keep reinstalling itself as a prerequisite with every install or update of one of our products that depend on it.

FOLLOWUP (06/19/08):  Actually, we ended it up having to revert back to the Visual C++ Runtime Libraries from Visual Studio 2005, as another prerequisite we were using (DTSearch) wasn't compatible with the new C++ libraries with VS 2008.  We'll check again next year.

View Full Article

Visual Studio Web Deployment Projects

So nearly a year and a half ago, a Microsoft team released a Visual Studio 2005 add-on that would add the "Web Deployment" project type to your IDE.  A few of the advantages of this new project type are:

• More control over the number of assemblies generated by a pre-compiled web project, as well as control over their naming.
• The ability to utilize the full power of MSBuild to customize your build process, including support for opening and editing the web deployment MSBuild project file directly in the IDE (with full intellisense support).
• The ability to define and use custom build-configurations inside Visual Studio, and define per-build configuration options (for example, you could define custom build configurations like “staging” in addition to the standard "debug" and "release").
• The ability to customize and modify a web application’s web.config file at deployment according to build configuration ("debug", "staging", "release", etc.).

Here is a link that discusses it further and gives a screenshot walkthrough of it:  http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx

Well, now that same team has included an enhanced version for VS 2008.  Here is a link discussing the improvements and additions:  http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx

Also, the IIS team at Microsoft has a new command-line utility called MSDeploy that helps with deploying and syncing web projects across all of the servers in your server farm:  http://blogs.iis.net/msdeploy/archive/2008/01/22/welcome-to-the-web-deployment-team-blog.aspx

Sounds like fun to me.

View Full Article

Windows Vista Virtual Store

Vista has a security "feature" that locks down certain system folders (for instance Program Files) from programmatic modifications.  However, it doesn't just deny your IO requests; instead it may or may not redirect it to some virtual store elsewhere on the file system (it's per-user too, so that could further screw your code up if you were writing out something global or machine-wide).  The best part is you don't know if you were redirected or not.  I've had it where I was being redirected to the virtualized location for writes and then when I attempted to read later, it wouldn't redirect me and I would be reading from the real Program Files.  Another odd thing is that it appeared to always read and write from the real Program Files location if the context was that of a locally-hosted web site.

Here's another blogger's discovery of it for further information:  http://www.hanselman.com/blog/VistasShowCompatibilityFilesAndTheScrumptiousWonderThatIsFileVirtualization.aspx

I don't know why I didn't know anything about this until now, but I quickly learned about .NET's Isolated Storage APIs.  Pretty useful for persisting configurations and such.  It was the solution to my problem in this case.  Here is a good article on it:  http://www.developer.com/net/net/article.php/3430541

I will warn you though that you should try to do the reading and writing from the same assembly from within the same application; otherwise, you end up getting different isolated storage stores for each call.  According to the many documents I read there is a way to call into a certain store even if .NET doesn't normally map your assembly and/or application to that location (you have to provide something called Evidence).  I couldn't get it to work and was running short on time.

View Full Article

Windows Installer Tools

Here is a site with a pretty thorough list of tools that help in creating and modifying MSI files:  http://www.installsite.org/pages/en/msi/authoring.htm

View Full Article