"AjaxControlToolkit is undefined"

Because we were still using an old Visual Studio 2005 solution which included a Web Site project, it was time to upgrade. We upgraded our Visual Studio 2005 solution to Visual Studio 2010 (and .NET 4.0), converted the Web Site Project to a Web Application Project and then, of course, the AjaxControlToolkit had to follow. I downloaded the latest build from their Codeplex site and updated the references in the different projects. I ran the website, and that’s where things got ugly…

Most pages worked nicely, but there were a few that gave an “AjaxControlToolkit is undefined” error. I removed all references to the AjaxControlToolkit, removed all the old versions of it from my machine, referenced the most recent version again, all to no avail. After Googling* Binging the error I found a LOT of possible solutions. These included:

  • Use the ToolkitScriptManager from the AjaxControlToolkit in stead of the built-in ScriptManager
  • When using the ToolkitScriptManager, set CombineScripts to false
  • When using the ToolkitScriptManager, set EnablePartialRendering to true
  • Clear the browser cache
  • Clear the ASP.NET Temporary Files directory
  • Use a (dummy) control to make sure the JavaScript files have been loaded correctly

Unfortunately, none of these possible solutions helped us with our specific problem. Our problem occurred when we, for instance, set the PositioningMode for a control from custom JavaScript using the AjaxControlToolkit.PositioningMode enumeration. The error was always from custom JavaScript. After looking around a bit more I found one site that mentioned something about changing the AjaxControlToolkit ‘namespace’ in JavaScript.  After playing around a bit I found out that changing the use of AjaxControlToolkit.XXX to System.Extended.UI.XXX provided the solution.

Hope this helps.

* Of course this is a weak attempt at a joke, but fact is that Google (the first 7 or so pages) only pointed me in the direction of the solutions that weren’t solutions for my situation. When I tried Bing for a change, I found something that put me on the right track pretty fast. Kudos to Bing!

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

Clicking ‘Choose items’ on the toolbox crashes Visual Studio 2008

I’ve had my current installation for a few months now, and I’ve used it for development purposes. Today I suddenly encountered an error when trying to add items to the Toolbox. Visual Studio 2008 simply disappeared… No errors, no warnings, it just went away.

After some searching and a lot of trying, I found that deinstalling the PowerCommands for Visual Studio 2008 did the trick. I’m guessing that the installation of a service pack (for either Visual Studio or .NET Framework) changed something somewhere, making Visual Studio disappear into thin air when having PowerCommands installed and clicking the ‘Choose items’ context menuitem. Anyway: the problem is gone now…!

According to some forumposts I read reinstalling the PowerCommands after this problem was solved does not cause the problem to reappear. I haven’t come to testing that yet ’cause I’m working on a deadline here… (Why do these things always happen when you have a deadline…?)

Hope this helps.

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.

Ajax Control Toolkit controls don’t show up in Visual Studio toolbar

Because I stopped working at Avanade and started my own company (this web site is under construction and in Dutch), I had to buy and install a new laptop. Everything went great and I was up and running in half a day. Or should I say half an evening… ;)

The next day I wanted to continue developing a web site we are working on. I needed one of the Ajax Control Toolkit controls, so I added it to my toolbar the way you should go about this (create a separate tab, right click, ‘choose items’, browse for the assembly). Strange enough, none of the toolkit controls showed up in my toolbar. I tried again, restarted Visual Studio and even restarted my computer. All to no avail…
After a while, I checked the ‘Show all’ option for the toolbar, and there were my Ajax controls, all of them disabled (grayed out). And if you think that is weird, read on for the cause of this behavior ;).

After some searching, I found something that I thought could be a solution. Unfortunately this did not solve my problems. Not even after repeating the steps several times. Luckily there were several people that commented on that same post, stating the proposed fix didn’t actually fix the problem. One of them said something about Microsoft wireless hardware being the culprit. I removed the wireless receiver of my Microsoft Wireless Notebook Optical Mouse, and the controls all appeared on the toolbar. Enabled and all…!

Now, whenever I need the Ajax controls in Visual Studio, I do the following:

  • Start Visual Studio (if not started already)
  • Open up a web page or a user control, or at least something you can place an Ajax control on
  • Open up the toolbox (note: no Ajax controls!)
  • Unplug the wireless device and see the controls appear like magic
  • Plug in the device: the controls should stay where they are

Hope this helps some of you…

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.

iTunes 8 translation glitch

I installed iTunes 8 on our laptop, and connected an iPod to check if all worked accordingly. The iTunes was installed in Dutch, so the displayed information was also. Apparently, when you’re Dutch, you get some extra capacity on your iPod, free of charge!

itunes_glitch

iTunes displayed the free space on the iPod as being ‘Gratis’, the Dutch word for when you don’t have to pay for stuff. Because free in English means both ‘not occupied’ and ‘for free’, the wrong one seems to have been translated into Dutch here…

By |September 10th, 2008|Error, Funny|1 Comment

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.

Unable to connect publishing custom string handler …

After developing a custom Web Service to be hosted in SharePoint (based on this HowTo article on MSDN) and deploying it on a testing environment, I got some entries in the EventLog over there, stating:

Unable to connect publishing custom string handler for output caching. IIS Instance Id is ‘xxxxxxxxx’, url is ‘http://internalsharepointserver/somesubfolder/services.asmx

The PublishingHttpModule trying to cache an unmanaged path seems to be the problem here. When enabled for a custom web application (such as my web service), it causes the eventlog entry each time certain requests like web service calls or static CSS files are made.

The quick solution is to simply remove the PublishingHttpModule for the custom web application. You can do so by editing the web.config file:
<httpModules>
    <remove name=PublishingHttpModule/>
    …
</httpModules>

To completely switch back to all default ASP.NET modules, use these settings in the web.config file:
<httpModules>
    <clear/>
    <add name=OutputCachetype=System.Web.Caching.OutputCacheModule/>
    <
add name=Sessiontype=System.Web.SessionState.SessionStateModule/>
    <add name=WindowsAuthenticationtype=System.Web.Security.WindowsAuthenticationModule/>
    <add name=FormsAuthenticationtype=System.Web.Security.FormsAuthenticationModule/>
    <add name=PassportAuthenticationtype=System.Web.Security.PassportAuthenticationModule/>
    <
add name=UrlAuthorizationtype=System.Web.Security.UrlAuthorizationModule/>
    <add name=FileAuthorizationtype=System.Web.Security.FileAuthorizationModule/> 
    …
</httpModules>

The number of fractional digits is out of range?

After extending a textbox with a NumberUpDownExtender, which comes with the AJAX Control Toolkit, I recieved the error “the number of fractional digits is out of range”. This happened when debugging my web application and using the extender. When using the web app in non-debug mode, nothing happened. This included the value change ‘not happening’.

Fortunately, this one was REALY easy, but it is not to be found on the web. That’s why I am posting this embarassing personal slip-up anyway. As it turned out, I switched the values in minimum and maximum. Make sure the Maximum property of the extender holds the highest value of the two and you should be good to go ;)

By the way, you would think something like this a) could be determined design- or compiletime, and b) could generate a better exception than ‘number of fractional digits out of range’.