Couple of XAML Editor enchancements in Visual Studio 2008 SP1

The "Go To Definition" functionality in the XMAL code behind editor has been enhanced in Visual Studio 2008. Invoking it on a reference of a control in the XAML code behind page, now takes the user to the definition of the control in XMAL code. What a pleasant change from the prior behavior where invoking the command would take the user to the designer generated code behind page.

So when you do this:

 

You get this:

 

instead of (in the .g.cs file)

 

The “Find all References” functionality has also been enchanced with the service pack. Invoking it on a reference of a control in the XAML code behind page, now inclues the references made in the XAML code also.

So when you do this:

You get this (Note the third reference in the tablecontrol.xaml file):

Programmatically creating DotNetNuke user passwords

When programmatically creating a DotNetNuke portal, the CreatePortal method API expects passwords that are already encrypted. In DotNetNuke, by default the passwords are encrypted using one way Triple DES algorithm. There is existing functionality in DotNetNuke that can be reused to encrypt plain text passwords. Listed below is some sample code that can be used.

Requirements: The code listed below uses the following classes that can be found in the assembly: DotNetNuke.dll

• DotNetNuke.Security.PortalSecurity
• DotNetNuke.Common.Globals
• DotNetNuke.Entities.Users.UserController

   1: string userName = "sampleUserName";

   2:  

   3: //generate a random 8 character password

   4: string password = UserController.GeneratePassword(8)

   5:  

   6: //get the machine's encryption key

   7: string key = Convert.ToString(Globals.HostSettings["EncryptionKey"]);

   8:  

   9: //encrypt the password with the machines encryption key

  10: PortalSecurity portalSecurity = new PortalSecurity();

  11: password = portalSecurity.Encrypt(key, password);

Line 4: We generate a random 8 character password using the static GeneratePassword in the UserController class. It is not required to use the method, you can substitute it with you own logic. Keep in mind to satisfy the password requirements configured in DotNetNuke.
Line 7: When users login, DotNetNuke encrypts the plain text password using the encryption key that is stored in the web.config. It then compares it to the encrypted version that is stored in the database, and if they match the login successed. We have to use the same encryption key or else the user will not be able to login even if he uses the right password. We use the Globals class which contains a collection of utility functions, to retrieve the encryption key.
Line 11: We use the Encrypt method of the PortalSecurity class to encrypt the password.

Programmatically checking if the required alias is available in DotNetNuke

If you try to create a portal with a alias that in not available, DotNetNuke will complain about it and not allow you to continue ahead. It turns out that this duplication check is done by the UI and not the business layer. So if you are programmatically creating a portal, you will have check if the required alias is available, because the DotNetNuke API does not do it.

Requirements:
All the classes used below can be found in the assembly: DotNetNuke.dll in the DotNetNuke.Entities.Portals namespace

Listed below is some sample code you can use the following code you programmatically check if the required alias is available in DotNetNuke.

   1: public static bool IsAliasAvailable(string alias)

   2: {

   3:     //need to make sure that the alias does not contain http://

   4:     alias = alias.Replace(@"http://", "");

   5:  

   6:     PortalAliasController aliasContoller = new PortalAliasController();

   7:     PortalAliasCollection aliasCollection = aliasContoller.GetPortalAliases();

   8:     return  !(aliasCollection.Contains(alias));

   9: }

Line 4: Since DotNetNuke does not store the "http://" part of the alias in its database, remove it from the string holding the alias before checking.
Line 7: Use the GetProtalAliases method in PortalAliasController class to get a PortalAliasCollection.
Line 8: Since PortalAliasCollection inherits from System.Collections.DictionaryBase, you can use the Contains method to check if the alias is available.

Programmatically creating DotNetNuke portals - Part 1

If the need ever arises you can use C# to use the DotNetNuke API to programmatically create portals you can use the code listed below. Of course the code will need all the right permissions to do this. You will need the following information to create the portal.

1. Portal Name
2. Administrator first name and last name
3. Administrator username and password
4. Administrator email
5. Portal description
6. Portal Keywords
7. Name (including path) of the template to the applied to the portal
8. Portal Alias
9. Server path (the path to the root of the Application)
10. If it is a child portal the child path (the path to the child portal folder)

Listed below are the required steps to create the portal and perform some essential house keeping activities:

1. Make sure that the alias does not contain the string "http://".
2. Check if the required alias is available.
3. Encrypt the administrator password with the machine encryption key.
4. Get all the required paths: template path, home directory and server path.
5. Create the portal.
6. Add the new http alias (url) to the Http handler.
7. Log the portal creation event tp DotNetNuke's event log.

In the next few days, I'll add a detailed post for each of the steps listed above.

Update 1: I've just posted an article on Programmatically checking if the required alias is available in DotNetNuke

Update 2: I've just posted an article on Programmatically creating DotNetNuke user passwords

Upgrading DotNetNuke from 4.4.1 to 4.8.4

Upgrading DotNetNuke from one version to another is fairly simple other than the fact that the changes in the web.config file need to be made by hand (although this is not true any more). I recently upgraded my system from 4.4.1 to 4.8.4 and faced a couple of issues that I have listed below.

Before you read any further, I would like to advice you to take a back up of your database and file system. I cannot emphasize enough on how important this is. I had to restore both of them several times in my beta environment during the recent upgrade as I worked through the issues.

Since I was skipping multiple versions, I decided to use the 4.8.4 install version of DotNetNuke.

Problem 1: Installing Package File OpenID_01.00.00_Install: Error

This was the first issue I faced. Because I do not need the provider I could continue ahead. I restored the database and file system. But before re-running the installer I removed the files

• Install\Package\LiveID_01.00.00_Install.zip
• Install\Package\OpenID_01.00.00_Install.zip

I have Googled for this error and am unable to find a solution for this problem.

Problem 2: Redirect Loop: Firefox has detected that the server is redirecting the request for this address in a way that will never complete

After the installation is complete, I tried to browse to the home page in Internet Explorer. It kept trying to load the page for 5 minutes, but never timed out. So I tried it in Firefox and that's when I got the message. If in your web.config the trust level is set to Medium, change it to Full. That should fix this problem. If you were already at Full trust, compare the code in Default.aspx with the version of the file in the installation package. If they differ, then replace the file on your system with the file from the installation package.

CodeSmith 5.0 Beta released

If you use the popular code generation tool CodeSmith, you'll want to download the latest beta release. It adds support for .NET 3.5. So now you'll be able to use LINQ in your templates. There are also some code generation performance improvements. Read more about it here.

(Via Rob Howard's blog)

Anti-virus and search indexing programs can affect Visual Studio build performance

On Scott Guthrie's blog, he has mentioned how sometimes anti-virus and search indexing programs can affect Visual Studio's build performance.

One issue I've seen reported several times are cases where virus scanners, spy-bot detecters, and/or desktop search indexing tools end up monitoring a directory containing a project a little too closely, and continually change the timestamps of these files (they don't alter the contents of the file - but they do change a last touched timestamp that VS also uses).  This then causes a pattern of: you make a change, rebuild, and then in the background the virus/search tool goes in and re-searches/re-checks the file and marks it as altered - which then causes VS to have to re-build it again.

Such programs are known to cause problems on production systems too.

(via: Visual Web Developer Team Blog)

Chance to win free .NET eBooks

Manning.com is giving away one free .NET eBook every day starting tomorrow until July 17, 2008. You can sign up for the lucky draw here.

Listed below are links to some of their books on Amazon:

• ASP.NET AJAX in Action
• ASP.NET 2.0 Web Parts in Action: Building Dynamic Web Portals
• C# in Depth: What you need to master C# 2 and 3
• LINQ in Action

One lucky guy will win the entire catalog of all Manning .NET  eBooks.

Sys.WebForms.PageRequestManagerParserErrorException

Recently I inherited a ASP.NET project from a colleague, who left the company. Call it Murphy's law or whatever, but the very first time I tried to make changes I got the following exception at run time: Sys.WebForms.PageRequestManagerParserErrorException. After a little bit of Googling I found out the cause. I was using the UpdatePanel and using a Response.Write in my PageLoad. Eilon Lipton's blog post has more details.