Solving the ProfileCommon ambiguous error

It is always fun when you stumble on some interesting error. In general, it is something that wastes too much of your precious time, but it is still rewarding to solve the problem. This is one of those.

The Problem

Today, I was updating a site to get it running on another server. I spent the end of the day yesterday working with new versions of a vendor’s libraries, so today we were merely deploying a site that was working on my local box to the server.

I had a couple of issues that were expected.

1.       One of the older sites referenced the 1.0 libs for AJAX (for .NET 2.0)

2.       Some tags from 2.0 were incompatible with 3.5

3.       The vendor libs had some changed interfaces

There were others, but once I got through the usual suspects, I found this one:

Compiler Error Message: CS0433: The type ‘ProfileCommon’ exists in both
‘c:WINDOWSMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET
Files{more stuff here}App_Code.DLL’
and ‘c:WINDOWSMicrosoft.NETFrameworkv2.0.50727Temporary ASP.NET
Files{same stuff as above}App_Code.z9v2fk16.dll ‘

I went through the normal Microsoft stuff. I deleted the ASP.NET Temporary files (more on this in the next post). I went through and restarted IIS. I recompiled the site and republished (using Publish Site in Visual Studio). I switched back to 2.0. Nothing.

I then did a search for ProfileCommon in my project and the first reference I found was flagged by Resharper as an Ambiguous reference. But it was running on my local box without a problem. So I searched to see if perhaps the vendor had coded his own ProfileCommon object anywhere. I would have never done this had there not been a new version of the library, as I would have known there was nothing wrong.

Side Note: If you have not looked into resharper, or competitive tools like CodeRush, you really should. Not only do these tools give you shortcuts for code blocks and refactoring aids, they will help find errors like this one. The site was running absolutely wonderful on my local box, despite the ambiguous reference issue. Without resharper, it would have taken much longer, and more pure trial and error, to fix the problem.

Check Google again. Nothing. Then I stumbled on a post where a person stated something like “when I delete the Profile section of the web.config, I am fine. But when I put it back, it has the same error.” Ah, a lightbulb lit in my sick little brain.


This is what you really want to see. ProfileCommon is a class autogenerated by the framework bits. It is generated when you add a Profile section to your code. In this case, here is my profile section:

<profile enabled="true" defaultProvider="MySqlProvider">


            <add name="MySqlProvider"

         type="System.Web.Profile.SqlProfileProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

         connectionStringName="MyConnection" applicationName="MyApp"/>



            <add name="SecondQuestionName" type="string"/>

            <add name="SecondQuestionAnswer" type="string"/>

            <add name="FirstQuestionAnswer" type="string"/>

            <add name="FirstQuestionSalt" type="string"/>

            <add name="SecondQuestionSalt" type="string"/>



I have taken some liberties with the naming (obfuscating clues to the actual app), but you can see that the point is to add elements to the user profile for an encrypted set of security questions. This is an extension on the standard provider. I must add a note here, not because it is relevant to the solution, but because it is important to people seeing this and wondering if I would do it this way today.

The simple answer is no. I find that a custom provider is a much better model than mashing random stuff in the ASPNET_Profile table. I have written about this before. Since I am not adding random bits to profile or different quantities of bits, having the automagically generated stuff is not really in my best interest. At the time this was built, 2.0 was brand new and I had a junior developer to work with, so using as much stuff out of the box was a good idea.

Now, back to our regularly scheduled error. The solution is to delete this section:


            <add name="SecondQuestionName" type="string"/>

            <add name="SecondQuestionAnswer" type="string"/>

            <add name="FirstQuestionAnswer" type="string"/>

            <add name="FirstQuestionSalt" type="string"/>

            <add name="SecondQuestionSalt" type="string"/>



You then attempt a compile, which fails due to this line in the code:

ProfileCommon profile = (ProfileCommon)ProfileCommon.Create(user.UserName);


And, you then put it back and compile again. It works.

More Notes

I am not 100% sure why this works, but it appears that something in the system creates a class. You then dink around with code, jump framework version, whatever, and the class does not go away. But, the Framework does not recognize the original class (from changing versions?) and creates its own. I think this has something to do with the name of the class, which appears to be somewhat random (perhaps hashed names?).

The exact why is not important. What ends up happening is the original autogenerated class is destroyed with the failed compile and when you successfully recompile the only class autogenerated is the new class.

Now, I would think this would be solved by completely clearing the Temporary ASP.NET files on both the server and the publishing development machine. This is not the case. There is also no code in the source tree. So Microsoft is caching these bits somewhere else. Where? Not sure yet.

One idea is it might be in memory. If so, a reboot would work.

Another idea is .NET has some other temporary location for files or alters the solution file on a compile or something. I do not have the time to test either of these theories, so you can have at it. It could also be something in the Temp files for Windows.

The short story is one way to defeat issues with autogenerated stuff is to remove the trigger and then replace it after a failed compile. I may, some day, have time to figure out exactly why this occurs, but tomorrow I have another site with the same error to fix.

Peace and Grace,


6 Responses to Solving the ProfileCommon ambiguous error

  1. David says:

    You Sir, are an utter genius.  I’ve looked and looked and looked and coudn’t see a way around this until I followed your suggestions.

  2. Gregory says:

    Everyone loves a complement … me included. I found this by beating my head against the wall numerous times and finally trying something way outside the box (my signature) and stumbling, in the dark, on the answer. Perhaps it is genius (I have a high tested IQ, at least), but it is probably more perserverance. Glad it worked.
    Peace and Grace,Greg

  3. John says:

    You are the Pater Familius of Profiles! Two days I’ve been fighting with this and all is well thanks to you.

  4. add site says:

    wow thanks for this useful info I’d love to try this.

  5. James says:

    Just stumbled across this after debugging some other MVC compilation issues using aspnet_compiler. Many thanks dude.

  6. DBG says:

    We just had this issue. We have DNN installed, and we think applying a security update last night caused this exception to start up. Your remove profile properties, compile, and then add them back in worked for us. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: