“The project location is not trusted”

After installing Windows 7 and Visual Studio 2010 on my laptop, I ran into the well-known message “The project location is not trusted”. I thought all I had to do was follow the instructions in this MSDN article to get my development share to be trusted again, but this doesn’t seem to work.

I already tried adding the new child group under the Internet_Zone in stead of the LocalIntranet_Zone, and using the complete server name and the server IP address in stead of the name of the server. All of these steps did not solve the message popping up…

I’m open to any suggestions, ‘cause this problem is beginning to drive me nuts.

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

Installing my laptop after a repair

I’m reinstalling my laptop after I got it back from a repair… EMPTY (grrr).

What tools shouldn’t I forget when preparing this laptop to be my development machine? Already have Visual Studio, SQL Management Studio, Office and the Windows Live tools installed… (and of course I have all kinds of tools at hand from my server like DebugView, Reflector and whatnot)

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.

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

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…

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

    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

  • Cool tool: DebugView

    Taken from the SysInternals website:

    The SysInternals web site was created in 1996 by Mark Russinovich and Bryce Cogswell to host their advanced system utilities and technical information. Microsoft acquired Sysinternals in July, 2006. Whether you’re an IT Pro or a developer, you’ll find Sysinternals utilities to help you manage, troubleshoot and diagnose your Windows systems and applications.

    One of the must-have SysInternals tools for a developer is DebugView.

    DebugView is an application that lets you monitor debug output on your local system, or any computer on the network that you can reach via TCP/IP. It is capable of displaying both kernel-mode and Win32 debug output, so you don’t need a debugger to catch the debug output your applications or device drivers generate, nor do you need to modify your applications or drivers to use non-standard debug output APIs.

    So that means that an easy Debug.Write (or Debug.WriteLine) statement is picked up by the DebugView tool, and displayed in the tool. From there, you can filter the lines, search them and more…!
    The code that made this screenshot: Debug.WriteLine(“Written through a simple Debug.WriteLine statement”);


    Technorati tags: ,,

    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