ASP.NET Blogs

I"ve been meaning to play around with Greasemonkey for a couple of years. Greasemonkey is a Firefox extension that allows users to install scripts that make on-the-fly changes to the look and feel of third-party websites. For example, adding price comparisons to Amazon or thumbnail images to Google search results. UserScripts.org has a large repository of Greasemonkey scripts.

I finally built my first script the other day. We"re putting together a new feature at Cozi that integrates partner websites with our site. Since the feature is not yet announced, I"ll just say that partners will add a link to Cozi on many of their database-driven pages. That link has a complex, page-dependent querystring. Until the partners do the work to add the link to their sites, we were limited to testing and demoing with hand-modified pages.

I wrote a little Greasemonkey script that finds the right spot on the partner pages to place the link, scrapes some context to construct the querystring, and inserts the link. Now we can test against the real sites and show a compelling demo. Of course, it only works on Firefox and it requires you to install both Greasemonkey and this script. Our partners will have to make minor changes to their sites before ordinary users can take advantage of the feature.

Some gotchas with Greasemonkey. Inserting, say, <b>Click here</b> is as simple as document.getElementById("spot").innerHTML = <b>Click here</b>. However, inserting a <script> node requires:

 var scr = document.createElement("script");
 scr.type = "text/javascript";
 scr.text = "createLink(" + p1 + ", " + p2 + ", " + p3 + ");";
 document.getElementById("spot").appendChild(scr);

Greasemonkey will definitely become part of my repertoire.

My development environment involves working on code that is not stored locally on my machine, but on a centralized development server on our network. I like working this way because it allows me to decouple my computer from IIS, and running the remote debugger (comes on the Visual Studio 2005 DVD) is really simple.

However, a problem arises when you try to run certain assemblies from a your remote development machine -- you get compilation errors telling you that an assembly can"t be loaded because permission request problems. I first noticed this issue when I started using the ASP.NET AJAX (formerly Atlas) binary builds. You will get one of the following two error messages when you try to build your project:

1) Request for the permission of type "System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=xxxx" failed.

2) ASP.NET runtime error: Could not load file or assembly "Microsoft.Practices.ObjectBuilder, Version=1.0.51205.0, Culture=neutral, PublicKeyToken=null" or one of its dependencies. Failed to grant minimum permission requests. [Note: The specific assembly information may differ depending on your project]

These errors occur because your remote development environment does not have enough permission to compile the ASP.NET AJAX (or other) DLLs on your system [For a nice explanation of Code Access Security, see http://www.15seconds.com/issue/040121.htm]. In order to give your remote development environment permission, you need to configure the Code Groups inside of the .NET Framework 2.0 Configuration MMC to allow your local intranet to be fully trusted by your machine. To do this, follow these steps on your development (local) computer:

1. Go to Control Panel-->Administrative Tools on your computer.
2. Click on .NET Framework 2.0 Configuration.
3. Drill down to My Computer --> Runtime Security Policy --> Machine --> Code Groups --> All Code --> LocalIntranet Zone.
4. Right click on LocalIntranet Zone, and choose Properties.
5. Click on the Permission Set Tab and change the Permission Set to “Full Trust”.
6. Hit Apply and OK and close the .NET 2.0 Framework Configuration window.
7. Restart Visual Studio

Now you should be able to build, debug and run your project with your ASP.NET AJAX DLLs included in the BIN folder. Happy Coding!

PS: I have heard that adding the problem DLLs to your GAC (on your machine and the remote development machine) will fix the problem, but I have not verified this. I did not want to do this in my environment because we work with different versions of AJAX and other DLLs and I want to keep different versions by project.

If you use BLL objects with ObjectDataSources to populate your GridViews, DropDownLists, etc, the ObjectDataSource tries to instantiate your BLL object using a parameterless constructor. If you don"t have a parameterless constructor (I usually don"t) available, you"ll get and error like:

No parameterless constructor defined for this object.

Description: An un-handled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.MissingMethodException: No parameterless constructor defined for this object.

The way to get around this problem is to handle the ObjectDataSource"s "OnObjectCreating" property and instantiate the object with any necessary parameters, and then assign that object to the e.ObjectInstance property. A quick and easy sample is below:

protected void objBLLClass_ObjectCreating(object sender, ObjectDataSourceEventArgs e)

{

BLLClass bClass = new BLLClass(param1, param2);

e.ObjectInstance = bClass;

}

-- If you aren"t using ObjectsDataSources yet, I highly recommend it for creating powerful, multi-tiered applications. There is a great intro-level series on 3-Tier Data Access at the ASP.NET main site. Once you understand the .NET 2.0 data model, there are many ways to customize the default objects to create really powerful applications! --

In a previous post, I mentioned an obscure ASP.NET issue that had me scratching my head for a while.

In order to track it down, I had to resort some dodgy debugging techniques which I wouldn"t call exactly scientific nor particularly complex, but they did help, so thought I"d share.

Basically, the page had many controls, and nested controls within many other containers and the like. The problem was difficult because there was no actual errors being caused and no obvious culprit to the "double request" problem I mentioned in the previous post, so I had to start eliminating sections of the page and sections of controls to see if it fixed the problem, and then start to isolate even further.

Problem was, once you start removing controls, the code behind does not compile, and then you have to start hacking your code behind so your site will compile and run. Once you remove more than a few controls, you need to make some serious changes and end up not really achieving anything by doing so. Ok for relatively simple pages, but a nightmare for complex pages. I wanted a way where I didn"t break the code behind, but could easily remove controls from the page to try and isolate the issue.

Enter dodgy debugging.

To do this, I simply wrapped portions of the page in a Panel control and set its visibility to false. This still allowed all the code behind to compile and run fine, but because the visibility of the panel was false, the content within the panel would not be rendered at all.

So basically, portions of the page were wrapped in:

<asp:Panel id="pnl" runat="server" Visible="false">
........
</asp:Panel>

I initially wrapped fairly large sections of the page, then reduced the number of controls within the panel, until I could isolate the control that was causing a double postback to my page.

Once I found the culprit, I fixed the issue and removed all the newly added panels from the page. Good to go.

After coding a .NET 2.0 project in VS 2005, I built and ran the project successfully with no compiler errors or warnings. However, once i added a Web Deployment Project and tried to compile it, it gave me the error "aspnet_compiler.exe exited with code 1". After doing some searching, I was able to find (more or less) the problem by running the aspnet_compiler manually with the error stack. The steps I followed are summarized below:

• Drop into the Visual Studion 2005 Command Prompt
• Run the aspnet_compiler.exe with the errorstack flag on your project (where Z:\PROJECT is the location of your project)
  • For Example: prompt> aspnet_compiler.exe -errorstack -v /PROJECT -p Z:\PROJECT
• Look for the problem in the output-- in my case it was [HttpParseException]: Unexpected end of file looking for </form> tag
• Since it doesn"t give you a specific line number, search through your ASPX files and try to find the error (I searched for <form>).

After fixing the problem, re-run the complier to ensure the problem is solved. After that, you will be able to compiler your Web Deployment Project.

I just ran into a client"s TFS configuration that, at first glance, caused a little concern.  This client has a very beefy dual server TFS configuration including a clustered Itanium-based data tier.  The client had previously tried to install TFS SP1 before and had painfully failed.

The original problem is that the Quiescence GDR that is required before installing TFS SP1 did not support clustering.  Microsoft fixed that and the current download is actually a version 2 that does support clustering.

The second problem is that the existing installation documentation mentions Itanium exactly once: Windows Server 2003 for Itanium-based systems, and Windows Server 2003, Web Edition are not supported.

To summarize the story, Microsoft through product support and the product team, confirmed that there is a problem in the documentation and not the product.  That is, the TFS Data Tier does support Itanium processors!

We did successfully and relatively painlessly perform the SP1 update to this TFS.  There was one problem due to renamed service accounts which initially blocked the installation of TfsQuiesce on the application tier, but Dave Hope readily provided a solution for that!

Just doing a little WPF work and have been using the NavigationService.Navigate() method to move between pages within my application.

Every time it"s called, the "Start Navigation" noise (sound / wav) plays, which is really frustrating.

The only way I"ve found of preventing it so far is by changing the windows global setting for navigation, there must be a simpler way though?

So, PowerShell has some good error handling, but being so used to .NET, I really missed my Try...Catch...Finally statements. Especially when I needed to make sure a block of code always executed. Well, after some playing, I think I have the solution! I"ve tested this function in a few different ways. I hope this turns out to be as helpful to someone else as it is for me. Maybe Microsoft will add this functionality to the core of PowerShell.

function Try
{
    param
    (
        [ScriptBlock]$Command = $(throw "The parameter -Command is required."),
        [ScriptBlock]$Catch   = { throw $_ },
        [ScriptBlock]$Finally = {}
    )
   
    & {
        $local:ErrorActionPreference = "SilentlyContinue"
       
        trap
        {
            trap
            {
                & {
                    trap { throw $_ }
                    &$Finally
                }
               
                throw $_
            }
           
            $_ | & { &$Catch }
        }
       
        &$Command
    }

    & {
        trap { throw $_ }
        &$Finally
    }
}

# Example usage 

Try {
    echo " ::Do some work..."
    echo " ::Try divide by zero: $(0/0)"
} -Catch {
    echo "  ::Cannot handle the error (will rethrow): $_"
    #throw $_
} -Finally {
    echo " ::Cleanup resources..."
}

Peter Waldschmidt of NCover fame has recently pulled together a team of developers under a new company called Gnoso. They have been working in conjunction with Grant Drake on enhanced versions of NCover and NCoverExplorer (now combined into a single tool suite). These have been in development for many months and there are lots of new features and stability improvements. Rather than try to summarize here, I recommend you read what Grant and Peter have to say about the new NCover 2.0 and NCoverExplorer 2.0 versions.

If you would like to use NCover 2.0 in conjunction with TestDriven.Net, you will need to install TestDriven.Net 2.9 or higher. If NCover 2.0 isn"t installed then TestDriven.Net will use the original NCover 1.5.8 and NCoverExplorer 1.4.8 versions. When NCover 2.0 is installed, TestDriven.Net will default to using the enhanced 2.0 versions. This version should also work if you are using TypeMock.

To perform code coverage on 64-bit Windows using TestDriven.Net, you will need to install NCover 2.0.2 Enterprise or higher. There was a compatibility issue with the original NCover 2.0 release, which prevented it from working when launched from TestDriven.Net. This is fixed in NCover 2.0.2.