Last post Aug 04, 2011 07:29 PM by 21a1ss3
Apr 30, 2006 08:13 AM|Deakus|LINK
I'm creating a multi-lingual web site using ASP.NET 2.0. So far no login required. Everything has been working fine while developing and test via VS 2005 on Windows XP Pro. But whn I compile and publish the site the Win 2003 Server throws the error
An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: BC30554: 'ProfileCommon' is ambiguous.
Line 54: End Sub
Line 56: Protected ReadOnly Property Profile() As ProfileCommon
Line 57: Get
Line 58: Return CType(Me.Context.Profile,ProfileCommon)
Line 54: End Sub
Source File: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\a9f6a360\6a92c38a\App_Web_default.aspx.cdcab7d2.tal-5bet.0.vb
The master page includes the main menu and the user options to specify the language of choice:
"?" + Request.QueryString);
void imgBtnFrancais_Click(object sender,
Profile.UICulture = "fr-FR";
the code behind files the incorporate the master page file include:
and the web.config file includes:
Please can you help to determine why I'm receiving this error once the site has been compiled an published.
Apr 30, 2006 09:54 AM|James Steele|LINK
Try using a fully qualified namespace where you reference a ProfileCommom type. The compiler is finding more than one ProfileCommon type and that is the reason for the error.
Protected ReadOnly Property Profile() As
You get the idea. That should help.
Apr 30, 2006 10:00 AM|James Steele|LINK
One more thing. Try compiling for release mode (if you did not do that already).
Apr 30, 2006 10:09 AM|Deakus|LINK
Thanks for your reply. Regarding your first post, it makes perfect sense to me but the problem is that I have not referenced ProfileCommon from anywhere in my project. As I'm aware, this is an auto-generated class so I guess somewhere, somehow this class
is being created twice?
I'm a newbie and not that familiar with compiling in release mode. I've been precompiling the entire site using aspnet_complier, is this the same as compiling in release mode, if not how can I perform this?
Apr 30, 2006 11:33 AM|Deakus|LINK
I'm still having problems with this. I've examined the master page and default.aspx.cs files, removed some code and performed some tests and I still get the same error. I'm fairly sure that the problem does not arise from these two files. Could it be:
1) the web.config file configuration, do I need to add anything specific;
2) IIS 6.0, configuration and/or
3) SQL Server 2005?
Is it possible to override the ProfileCommon class or at least force the application to use a specific ProfileCommon class (i.e by adding adding the namespace?)
Should I add anything to the Global.asax file?
Please can you provide some hints for me.
May 01, 2006 12:41 PM|James Steele|LINK
May 01, 2006 12:45 PM|James Steele|LINK
May 01, 2006 06:41 PM|Deakus|LINK
Thanks again James for your assistance. I've cracked it though. Unfortunately the error messages I was receiving weren't providing enough clues (for me) to find the root of the problem easily enough but fortunately the solution was very simple to implement
once I had an idea of the problem.
I started a new project and pieced it together bit by bit using the files from my previous project (the one giving the errors) just until I started to receive my first error, which was...
"Failed to generate a user instance of SQL Server due to failure in retrieving the user's local
application data path. Please make sure the user has a local user profile on the computer. The
connection will be closed."
This occured when my localisation code was added (as expected)
I googled this error and found out the problem relates to the SQL Express instance that was being automatically generated, as well as the local user name on the server.
Then I read a post at
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=125227&SiteID=1 by a member that cracked it on the head for me. I didn't follow his instructions completely since my set up was different than his but I used the suggested aspnet_regsql utility to register
my existing sql server 2005 db to be used by the profile provider and VOILA!! the errors disappeared.
Also I added to web.config file :
<add name="LocalSqlServer" connectionString="data source=xxx.xxx.xxx.xxx\sqlexpress;Initial Catalog=myDB;User ID=user;Password=pass"/>
May 01, 2006 07:06 PM|James Steele|LINK
May 03, 2007 08:34 PM|GE-Unit|LINK
The main thing to take away from that as as side post here as this article is fairly old. Is that there is a another version of the file that the compiler is seeing with the same name. That is why its ambigous....
Jul 28, 2007 11:00 AM|speenr|LINK
I just had the same issue with "ProfileCommon". I commented
Then I rebuilt the solution and republished the web site. After that everything ran good. I then went back into the code above and the project had uncommented that section. I'm not sure what was going on, but all is fine now.
Aug 19, 2007 10:34 PM|stevemol|LINK
Now I've caught the bug... and it really has me stumped.
In my case, the whole site (and it's not very big yet) works fine on my XP Pro development machine, but when I try to copy or publish it to the Win2K Server, it says ProfileCommon is ambiguous and won't run.
Here's the web.config file in case anyone can find the problem...
Mar 19, 2008 07:19 PM|Bugs66|LINK
I am having this problem after turning on membership to an existing application. Works fine on dev machine. Works fine on production clone. Doesn't work on production machine. I get BC30554: 'ProfileCommon' is ambiguous. I have tried everything short
of rebooting the production server. Still not able to resolve.
Nov 20, 2008 12:24 PMemail@example.com|LINK
I had this problem and solved it by uploading the PrecompiledApp.config file to my live server.
Dec 29, 2008 06:55 PM|WikiDiscovery|LINK
I know the problem. I just worked it out now; at least I think. I will start off by saying I always publish apps with the “Allow this precompiled site to be updateable” unchecked,
because I like the added security idea of compiling all the code and only leaving page markers behind. In fact, I assume we do not get the BC30554 error because all assemblies and code are compiled into their own unique constructs when you publish apps in
this way. However, our site now has hundreds of pages and the idea of compiling the entire applications to fix a static link or grammar issue on a single aspx page has become a daunting task.
Anyway, so I decided to publish the next version of the App with the “Allow this precompiled site to be updateable” checkbox, checked. I kept getting failures though. I had no idea
why. FYI, to get details of the build error, be sure to: In visual studio 2008(or 2005), go to options -> projects and Solutions -> and then check the "show Output Window when build starts". This will at least print out the raw compile issues. Even then, I
saw nothing but BC30554 ‘ambiguous’ errors. After hunting the internet, I found nothing with the exception that the BC30554 errors were related to User Controls. Then it hit me… I have several User Controls with the same name, but in different directories.
By changing the physical name of the user control, the source code file (which should change with the name) and by making sure the inherited class is changed (if it is required), from what I see, the app compiled and things work fine.
My suggestion is to remove any extra user controls that are not needed. My initial thought when I started my project almost 2 years ago was that you needed separate user controls
with SSL directories v.s. using the control within static non SSL directories. I found out later that it does not matter. The server knows how to render the user control. If the control is rendered over an SSL connection even though it is located in a directory
that might not be secure, the server still knows to render the control over an SSL. Just be sure to make the register reference absolute or use a ~ if you are using relative linkages.
Moving along; remove duplicate controls if you are only using them to handle secure and unsecure situations. If you have controls you might have copied and then made finite changes, removing them is an issue obviously. This is when you
should make the name change as stated above.
I hope this helps?
Oct 13, 2009 04:21 PM|armandos|LINK
I had the same issue, I went to the bin folder and deleted all the dlls not needed and boom!,
my project worked good on the server.
Aug 04, 2011 07:29 PM|21a1ss3|LINK
I have now experienced this problem. It arose from the fact that I have added a link to a dynamically created library. This problem persists even if you delete a reference to this library. The solution I have been quite simple: remove the library from the
folder bin. The name of the library begins with app_code