August 2006 - Posts

Windows service setup projects - Unable to build custom action error

I ran into another under-documented snag upgrading my solution to Visual Studio 2005. It has a Windows service used for behind-the-scenes maintenance sorts of tasks that run on a regular basis, and a corresponding setup project. Now, it's also got setup projects for command-line apps and web apps, and all of those upgraded fairly well--it got confused on the output, so I had to delete and re-add the appropriate Primary Output to each project, but after that, all the setup projects built fine, except the Windows service one.

It gave this error in the Output window when I tried to build it.


Building file 'C:\whatever\MyProjectSetup.msi'...
ERROR: Unable to build custom action named 'Primary output from MyProject (Release .NET)' because it references an object that has been removed from the project.
Build process cancelled

In the Error List, when I double-clicked on this error, it took me to the Custom Actions window for this project. As documented in this Microsoft Knowledge Base article, the project had the Primary Output listed as a custom action for all four custom action types--Install, Commit, Rollback, and Uninstall. The Uninstall one is the only one highlighted, though, with a red wavy underline. This told me nothing more about the error.

Sometimes in cases like this, when I open the project file in Notepad, it can make it clear what's wrong. For instance, when a Crystal Reports report loses its corresponding .cs file, I can reassociate them by manually editing the project file and reopening the project. But .vdproj files are different beasts--much uglier and harder to manage in Notepad.

That KB article said it was set up correctly, and yet it wasn't building. So I tried deleting all four custom actions, and re-adding them per the directions in the article, and it built, installed, started and ran, and uninstalled just fine. (For what it's worth, Microsoft did document this process in an MSDN Library article.)

One difference I see is that all my project outputs in all my setup projects, including these custom actions, now read "(Release Any CPU)" instead of "(Release .NET)". I'm not sure what difference that makes, nor why I should care (and have to correct it manually), but as far as I can see, it's working fine now. We'll see if I get any nasty surprises when I give it to QA for testing.

Ambiguous match found

Looks like I've been away a few months. Sorry 'bout that. I've had stuff to write about but not enough time to set aside to do so, which is a little ironic; one of the main reasons I created this blog was so I could take 5 minutes and jot down stuff I find out while developing, largely in case it helps others, not so I could write my usual verbose 5000 word essays (which is what my AspAlliance site is for!).

So, on that note, I wanted to share how I solved a goofy error that made no sense. I was upgrading a good-sized web application from .NET 1.1/Visual Studio 2003 to .NET 2.0/Visual Studio 2005 using Scott Guthrie's well-written instructions and the Web Application Projects add-in. Going through VS2005's automatic conversion and building it was pretty painless when I followed Scott's instructions; one wrinkle I ran into is that it forgot about the three web projects, so I had to add those manually using "Add Existing Project" after I converted the others.

But it built and I went through the app and everything was fine. I didn't do the "Convert to Web Application" command on the whole project, preferring to keep a closer eye on what it changed, and touch it up after. So I started doing it folder by folder per Step 8 inScott's instructions, and it seemed to work great, until I got to one particular page and got this error.


Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Ambiguous match found.

Source Error:

Line 1:  <%@ Control language="c#" Inherits="MyApp.Namespace.MyCoolControl" CodeBehind="
MyCoolControl.ascx.cs" AutoEventWireup="false" %>
Line 2:  <%@ Import Namespace="
MyApp.OtherNamespace" %>
Line 3:  <div class="openingParagraph">

Source File: /MyApp/Namespace/
MyCoolControl.ascx    Line: 1

So it says Line 1, Line 1 is highlighted, and yet, the only reference in line 1 is a fully-qualified one. To be safe, I pulled all my custom assemblies into the invaluable .NET Reflector and double-checked, and there was only one instance of that class name anywhere.

I tried what I normally try when I get weird ASP.NET errors I shouldn't be getting, a process many of you are probably too familiar with if you've worked with ASP.NET very long. I restarted IIS, deleted and recreated the application in IIS Manager, deleted the Temporary ASP.NET Files directory for MyApp (after closing Visual Studio), restarted Visual Studio and rebuilt the project, etc. None of these helped this time.

Scott's instructions mentioned this error in some cases, notably the IE WebControls, but the solution has been to specify the full namespace, not just the class name, so that didn't help me. Other Google search results were similarly unhelpful, until I found the blog of a guy named Eran Sandler who talked about his "Ambiguous match found" error and how he solved it--two protected fields with names that differed only in case, apparently confusing reflection.

Sure enough, my code had the same problem--I had myRepeaterControl (name changed to protect the innocent, of course), and MyRepeaterControl in my code-behind. The latter wasn't used and was probably left in mistakenly; I removed it, it still built fine, and the control worked great.

Thanks, Eran!

Posted by pjohnson | 55 comment(s)
Filed under: ,
More Posts