Fix available for IE8 asp:menu problem

I just read an interesting article on Bertrand Le Roy’s blog. The most important information:

It so happens that the menu control is making a bad assumption on what the default value for z-index should be. We debated this at length with the IE team, but it became clear as we did so that they were right and that we were wrong. We had to fix that.

So here it is, the patch for menu is out and you can apply it to build IE8-compatible ASP.NET WebForms sites…

Windows 2000, XP, Server 2003:
http://code.msdn.microsoft.com/KB962351/Release/ProjectReleases.aspx?ReleaseId=2294

Windows Vista, Server 2008:
http://code.msdn.microsoft.com/KB967535/Release/ProjectReleases.aspx?ReleaseId=2328

(the KB article is not yet ready but will be published shortly)

Read the entire article over here: http://weblogs.asp.net/bleroy/archive/2009/03/23/asp-menu-fix-for-ie8-problem-available.aspx

In this mode, command line arguments will not be passed to the executable

When trying to pass some command line arguments to a Console Application, I got the following message: “The current project settings specify that the project will be debugged with specific security permissions. In this mode, command line arguments will not be passed to the executable. Do you want to continue debugging anyway?” (see image)

The current project settings specify that the project will be debugged with specific security permissions.  In this mode, command line arguments will not be passed to the executable.  Do you want to continue debugging anyway? 

I didn’t run in to this earlier, but yesterday it suddenly popped up. But I did change my zone security, so that might be of some influence… Apparently, this is because of the Debug in Zone settings you can find at the Security tab of your project properties. Deselecting the ‘Enable ClickOnce Security Settings’ checkbox will solve this ‘problem’ for you.

For more information about Code Access Security, take a look over here: http://msdn.microsoft.com/en-us/library/z17ceyya.aspx

HowTo: Add a body onload script to a page that uses a MasterPage

When you use a MasterPage to define the design of your website, you might come across the problem that there is no body element in a web content form. This can be a problem when you want to add an onload script to a specific page. You could of course add the onload on the MasterPage, but you might not want the script to run on every page. There are several workarounds to fix this ‘problem’. The one I used last week was to do the following:

  1. Add the runat=”server” tag on the body in the MasterPage
  2. Add a unique ID on the body in the MasterPage
  3. Add a method to the MasterPage to set the onload for the body. This might look a bit like this (of course you can also have the script for the load be a parameter for the method):
       1: internal void SetBodyLoad()
       2: {
       3:     MasterPageBody.Attributes.Add("onLoad", "initialize()");
       4: }
  4. Add this line of code in the Page_Load of the page you want to have the onload:
       1: ((MasterPageName)Master).SetBodyLoad();

 

This worked for me! Hope this helps.

By |January 30th, 2009|.Net, HowTo|1 Comment

Nice new addition to ASP.NET

Scott Guthrie posted about a cool new ASP.NET server control: Chart. It can be used for free with ASP.NET 3.5 to enable rich browser-based charting scenarios.

Read more over here: http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx

Inline wrappers & Response.Redirect() == Error

While developing a page that was to be used through an inline wrapper, I got an error: “Validation of viewstate MAC failed”. This error can usually be resolved by disabling event validation, viewstate encryption or viewstate for the MAC. In my case these solutions did not resolve the issue.

After some testing Response.Redirect appeared to be the cause. I changed the page so it doesn’t need the redirect any more, and the problem disappeared. I’ll try if ending the response when redirecting will help, but for now I can continue working…

Hope this helps.

An inline wrapper and having too much on your head

We developed an ASP.NET page (A) to be wrapped in an existing PHP page (B) using an inline wrapper. After a few days in which both pages displayed nicely, our page (A) suddenly got displayed twice inside the existing page (B).  And even weirder was that the postbacks of the first occurrence didn’t work, and the postbacks of the second were executed outside of the wrapper.

We had changed some stuff the night before, so I finally checked the file line by line against an earlier version. The problem we eventually found was small and not too easy to find. But so easy to solve… Because of an external editor, the page’s (A) header had received an ID, probably because of the runat=”server” tag. Removing the ID tag was enough to have both pages working fine again.

StyleCop v4.3 now available

StyleCop version 4.3 was released last tuesday. A short summary of what version 4.3 brings us: 

  • Various bugfixes, including fixes for VS integration issues
  • Rules documentation is included and integrated into VS “Show Error Help”
  • New rules, see blogpost for the rules
  • Branding change from Source Analysis to StyleCop

    Links
    StyleCop blog: http://blogs.msdn.com/sourceanalysis/
    Release announcement on the StyleCop blog: http://blogs.msdn.com/sourceanalysis/archive/2008/08/19/stylecop-4-3-is-released.aspx
    StyleCop 4.3 download: http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sourceanalysis&ReleaseId=1425

  • Running code analysis on a custom stsadm command gives errors CA0052 and CA0055

    When you want to implement a custom stsadm for SharePoint, all you realy have to do is implement the Microsoft.SharePoint.StsAdmin.ISPStsadmCommand interface. Because I develop on a machine with no SharePoint installed, I (only) copy the assemblies I need to develop locally. For the stsadm command I was working on recently (more on this in a future post) I only needed the Microsoft.SharePoint and Microsoft.Office.Server assemblies. Or at least I thought so…

    After implementing the functionality I tried running code analysis, and I got two errors:

    CA0052 : No targets were selected.
    CA0055 : Could not load AssemblyName.

    After trying several ways to fix this, I finally compiled the project on a machine with SharePoint installed. At that point, compiling and running code analysis both worked fine. Code analysis then gave a warning that pointed me to the solution of the problem:

    CA2123 : Microsoft.Security : Add the following security attribute to ‘ClassName.MethodName(string)’ in order to match a LinkDemand on base method ‘ISPStsadmCommand.GetHelpMessage(string)’:  [SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true)].

    Apparently the attribute requires an extra reference. When I copied that assembly (Microsoft.SharePoint.Security) to my non-SharePoint development machine, all worked correctly. FYI: I did add the attribute code analysis suggested by the way.

    A not so clear Visual Studio code analysis message (CA1308)

    While writing a custom stsadm command for SharePoint (more on that in a future post) and having to do something based on the command the user typed in, I used ToLower(CultureInfo.InvariantCulture) on the command string to be able to check without the hassle of differences in casing. When I ran code analysis on my project, I got this somewhat cryptic message:

    CA1308 : Microsoft.Globalization : In method ‘CommandParser.Run(string, StringDictionary, out string)’, replace the call to ‘string.ToLower(CultureInfo)’ with String.ToUpperInvariant().

    So in order to solve a code analysis warning I should change lowercasing a string to a call to ToUpperInvariant? That seems a bit strange, right? Because I was almost sure this could not be a typo, I searched around a bit. When you search for the error number, you get an explanation from Microsoft through the MSDN article Normalize strings to uppercase [1]. Apparently there’s an issue with a small group of characters which are unable to round trip when converted to lowercase. For more information: have a look at Michael Kaplan’s post Get off my (lower) case! (or: Casing, the 1st) which explains it pretty well [2].

    Hope this helps some of you ;)

    [1] http://msdn.microsoft.com/en-us/library/bb386042.aspx
    [2] http://blogs.msdn.com/michkap/archive/2004/12/02/273619.aspx

    The absolute minimum every software developer …

    One of the posts that is being read quite frequently over here is HOWTO: Encode a password using MD5 in C# (or: howto calculate the MD5 hash for a string). One of the (many) reactions to that post was from one Simucal, stating:

    Also, to the original poster, Rick van den Bosch… shame on you for using ASCIIEncoding.Default.GetBytes().  You do realize that would seriously restrict the usefulness of your method to working only in languages that ASCII has the character sets for, right?

    I suggest you read this article entitled:

    The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

    Yes, I do realize that using ASCIIEncoding.Default.GetBytes() would seriously restrict the usefulness of the method to working only in languages that ASCII has the character sets for. The primary reason for the post was to illustrate the way to calculate the hash. Representing it as a string was only there to be complete for a specific scenario. I did not try to write a hashing function for every language ;)

    That being said, the post Simucal refers to is a good one, and it truly is the absolute minimum every software developer absolutely, positively must know about unicode and character sets. And I guess there are no excuses ;). So if you haven’t done so already, go and read it.