asp.net someusercontrol_ascx is defined in multiple places error - asp.net

I've had this intermittent issue when using asp.net. My site is dynamically compiled. Sometimes when I modify a user control my web site complains that it is defined in multiple places. It almost seems like the old control did not get removed from the asp.net temporary files and the updated control is compiled to the same directory so it's defined in multiple places. That would make sense to me except for the fact that I have no control over what is in the Temporary ASP.net Files folder.
I've read that having circular references will cause this. I've made sure that I don't have circular references. Even with the simplest site I've seen this happen.
I've noticed that when using Master Pages this error seems to come up a lot more frequently.
I've read that a hotfix tries to fix this issue but I've gotten this error after applying the hotfix.
If I get the file causing the issue and make an edit to it then the error goes away. Even if I just put a space in the file it will resolve the error.
I can also get the error to resolve sometimes by visiting other pages of the site that might not use the user control and hitting refresh. This does not always work.
If I set the site to debug the error never happens. If I set it so that it comiles on a page by page basis then the error does not happen as much but still happens.
Below is what the error looks like.
Compilation Error
Description: 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: CS1595: '_ASP.Header_ascx'
is defined in multiple places; using definition
from 'C:\WINNT\Microsoft.NET\Framework\v1.0.3705\Temporary
ASP.NET Files\root\afwew23d\asdfasd423\asdf23.dll'
Edit:
I'm using .net 2.0 (3.5) even though the error above says 1.0. I got that error from another source since I can't reproduce the issue every time. But the type of error is the same.
Edit 2:
Thanks gisresearch for your research. There was one statement in the link you provided:
One caution even if you have debug=false, is that if you go in and change something in one of your aspx pages, this page will have to be recompiled, but this doesn’t cause an appdomain reload so the whole application is not batch compiled again. This has the effect that the page will now get recompiled separately and get its own dll, so don’t change your aspx pages on a live server too often.
There is a setting in machine.config determining how many recompiles are allowed before the app domain restarts, by default it is set to 15, so after 15 recompilations the app domain will restart, just as it would if you touched the web.config or touched the bin directory.
This seems to say that when debug=false and the site has already been visited and compiled, if you change a page it will only compile that one page. That sounds like it could cause problems. I had thought changing a page or user control would cause the entire app to recompile.

Do you have two user controls with the same file name in diferent Folders of your Web App?
That sometimes will cause this issue.
If I set the site to debug the error
never happens.
when debug=true, the asp.net compiler don’t batch compile, when debug=false it does batch compile and may cause this issue.
The Read this post.
There is a conversation about the same issue.
re: ASP.NET Memory: If your application is in production… then why
is debug=true Monday, April 24, 2006
2:39 PM by Robbie Coleman We did get
an error for a UserControl that it
reported it could not load the
FileName_ascx class due to multiple
versions in the Temp ASP.NET folder.
We identified that we had two user
controls with the same file name in
diferent Folders of the same Web App.
The also had diferent namespaces and
never through this exception until we
set debug="false". We even wiped the
Temp ASP.NET directory clean on an
IISreset.
The only way we could fix the error,
was by renaming the ascx file of one
of the two.
Is this correct...? Was there a better
way to fix this?
BTW... [KissUpText] Tess, your posts
have been very helpfull to our
development team, and we really
appreciate all the information you
have given away. [/KissUpText]
re: ASP.NET Memory: If your application is in production… then why
is debug=true Tuesday, April 25, 2006
1:56 AM by Tess Hi Robbie,
Thanks for the nice comment:)
I am assuming that you are getting
"CS1595:
'UserControls.WebUserControl2' is
defined in multiple places; using
definition from
'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET
Files\usercontrols\293a1a4b\dbb2d387\cisxatg3.dll'
" or similar.
The problem basically occurrs if you
are using src rather than CodeBehind
and your cs or vb files contain a
definition for exactly the same class
in exactly the same namespace. The
error is really the same as what you
would get if you tried to compile a
dll with another class defined twice
in the same namespace.
The reason i am saying it happens when
you use src is because if you would
use CodeBehind you would have gotten
an error at compile time.
If the usercontrols are really the
same I would avoid creating a copy,
and instead using the one from the
other folder. If they are different I
would either give the different names
if possible, and if not, make sure
that the source classes are in
different namespaces, such as
ProjectName.FolderName.MyUserControl
The reason you are seeing it now and
not before is because you are now
batch-compiling everything into one
dll.
Hope this helps.

Related

added asp control gives error 'is not declared. It may be inaccessible due to its protection level.'

VS 2010 VB.NET Website project
On a masterpage of a website any controls I add to the master page aspx file gives the compile error: 'xxx' is not declared. It may be inaccessible due to its protection level.
This is for any new control I add, like an asp:button or an asp.panel, or a div with runat='server'.
In VS 2010 on the code behind the added controls are accessible, intellesense works, everything appears just fine, but when I compile I get a generic failed to compile error, but VS lists no errors, if I look at the build output I see the error above.
If I do not reference the added controls in codebehind the site will compile and the controls will be on the screen.
So whatever 'hidden' file VS has must be out of sync with the aspx file, problem is I see no such files in the project folders.
I did copy the master page a few weeks ago and rename it as a backup, but I edited the original not the copy. Still this may have caused the problem even though I just recently discovered it. It is possible I had not actually added any new controls that were referenced in the codebehind so I may not have noticed the problem.
How can I resolve this problem - is it possible to rebuild or resync this 'hidden' file?
I suppose I could create a new master page and copy the code over it that would work, but I have a lot of other pages referencing this master page...what a mess.
In the page declaration, change CodeFile to CodeBehind (or vice versa.)
Check this link: CodeFile vs CodeBehind
Whether it is a Web site or a web application affects how the reference to the code file is stated. (BTW, it's a web application if there's a .vbproj or .csproj file.)
Space constraint(low disk space) on drive was giving this vague message.
..'is not declared. it may be inaccessible due to its protection level.'
Resolved by creating space on drive.

cd_link.PageLink GetLinkAsString(...) causing pages to fail every other request

I am currently migrating from Tridion R5.3 to Tridion 2011. I am having issues with serving some pages through the presentation server. For reference all of my web pages are classic ASP and I am running them on IIS7.5.
I have have a page located at http://www.example.com/widget/index.asp. When I first access the page I get a The page cannot be displayed because an internal server error has occurred., if I then refresh the page it loads fine, if I refresh the page a third time it comes up with the error. The page works every other request.
I have enabled Failed Request Tracing on my website and I am getting the error
ASP_LOG_ERROR
LineNumber: 87
ErrorCode: 800706be
Description:
Note there is no description.
The code being called is
85: Dim objTranslationPageLink
86: Set objTranslationPageLink = Server.createObject("cd_link.PageLink")
87: strTranslatedPageLink = objTranslationPageLink.GetLinkAsString("tcm:0-12-1", "tcm:12-123456-64", "", "", "TranslationFound", False)
88: Set objTranslationPageLink = Nothing
It looks like there is no problems creating the cd_link.PageLink object, just when calling the GetLinkAsString(...) function.
I use the cd_link.PageLink object in lot of other pages with no problems but it seems with pages that use this specific piece of code experience the problems.
I was thinking it could be something to do with caching pages however I turned off caching of ASP pages (IIS7 > ASP > Services > Caching Properties) and still had the problem.
Any ideas?
edit1
The code worked fine on Windows Server 2003 IIS6. I am trying to make it work on Windows Server 2008 IIS7.
edit2
It appears that the page is creating a lot of cd_link.ComponentLink and cd_link.PageLink objects. I have a test page in which I create 10 ComponentLink objects I get the error (every other page) but if I reduce this to 5 ComponentLink objects it works every time.
edit3
My cd_core.xxxx.xx.xx.log has the following errors
2012-11-02 11:55:34,027 ERROR XMLConfigurationReader - Error while validating file 'cd_link_conf.xml' with schema 'schemas/cd_link_conf.xsd'. cvc-complex-type.3.2.2: Attribute 'DefaultRootLocation' is not allowed to appear in element 'Publications'.
edit4
Thanks for bearing with me. The problem I was having with my cd_link_config is fixed and doesn't appear to have been be related. I now have no errors in my any of the four log files (cd_core, cd_deployer, cd_monitor, cd_transport) but the original issue persists.
Looks like you are running the CD Link windows service and the following hotfix might help to resolve your issue. I have not tried this hotfix but the description says Page link fails on second attempt of accessing the page, so that means it might work sproadically depending on the logger memory resources.
Anyway worth looking at this hotfix : CD_2011.1.0.78355
Description: The Linking windows service was not correctly cleaning up a logger memory resource on certain windows platforms
It is a long time since I worked with Classic ASP and SDL Tridion, but double check the following
Is the linking service running on the server?
Check your cd_licenses.xml file is in place
Validate that you have a correct cd_link_conf.xml and cd_storage_conf.xml (these changed from 5.3 I believe)
Look in the Application and Tridion event logs for clues
The Tridion linking log files
That error code seems to imply that the Linking DLL is not registered properly.
That is all I can think of for now.
I didn't realise that 2011 actually schema-validates the config files, but in any case, now the error is clear. I'd suggest doing the validation yourself in an XML editor such as XML Spy. That should point out exactly what's wrong with the configuration file.
To routinely check your configurations, you may find it interesting to script it as described here.

Why does Web developer built-in web server serve zero byte files suddenly?

Visual Web Developer 2010 Express. C#, MVC3.
Clicking F5 to debug.
It starts up the built-in ASP web server on http://localhost:50188/
The Output window tells me WebDev.WebServer40.EXE is loading loads of DLLs.
Up until yesterday it worked. Today all URLs give me a blank page!
All controllers (all that changed yesterday was one controller, and some of its views; but it was working yesterday after all those changes). Same results in two different browsers. Use a different port gives an error (Telling me that there is something listening on port 50188!!) No errors anywhere. Just 0 byte files received.
My question is What happened and how do I fix it?
More Info:
Rebooting the machine made no difference.
I also found the obj/Debug directory and deleted it. It got recreated next time I hit F5 to debug. Still exactly the same problem!
And I went back 24hrs, in git, and still the same problem. So I'm sure the problem is not being caused by any of my source files. (The .csproj file is in git too.)
Look for a file called app_offline.htm (in your web root directory). It is a zero byte file. If it exists then this is served instead of any of your content! (It is a great feature if you wanted to take your site down for maintenance - put a custom message in that file.)
The Fix: Simply delete it and your website starts working again!
It appears (and I'm not sure about this) that the file is put there automatically when both you and your website want to access the DB at the same time. It should be deleted again automatically. But I guess a crash of something might leave it behind.
(To be honest, I think it would have been much wiser to put some content in app_offline.htm, explaining what it is and why it was automatically created. Quietly creating a zero-byte file is a tad sadistic...)
More information here: Why does app_offline.htm keep appearing in my web project?
And here: http://www.daniweb.com/web-development/aspnet/threads/215912/why-app_offline.htm-is-created-automatically-whats-the-mystery#

Most elements of an ASP.NET page are not rendered after random idle time

We have been trying to figure this one out for a while now, without any luck.
The symptoms are as follows:
After some idle time of a specific ASP.NET 2.0 application (can be from several hours to days), one of the pages in my application stops working.
When viewing the source of the page I see many elements missing, elements that are usually there, such as: reference to WebResource.axd, the __doPostBack() function, all of the UserControls and more.
A reference to ScriptResource.axd, and the __VIEWSTATE are there.
After recycling the app pool, the application starts working correctly again and everything renders well.
This only happens on a specific server, when deploying the same application on a different server, this error does not occur.
The page that the error occurs on has only one UserControl which is not rendered when the error occurs. Nothing special happens when this page is loaded.
We tried doing periodic client refreshes, but that did not help either.
Thanks in advance.
It was a caching issue. There was a part in the code that hid specific controls when the cache was invalid. That explains the missing code parts.
I am still not sure why the cache was invalid on that specific server.

ASP.NET showing 404 for some .aspx files even though they exist

I just redeployed one of my sites today and suddenly some (but not all) of my .aspx files are redirecting to my 404 handler.
I've scrutinized the security settings on the offending files, comparing them line-by-line with other .aspx files that are serving correctly, with no luck.
The files 404'ing files were indeed ones I had been working on, and were replaced during the deploy. But then again, some of the other files I was working on are coming up fine. Naturally, the changes were not the sort of thing that would cause the errors I'm seeing, and the site runs perfectly in my dev environment.
Any idea what could be causing this?
ANSWER: User Error (as always)
Looks like my deploy script was skipping .ascx files. (One of the minor changes between last deploy and this one was adding a couple usercontrols.) The page would start loading, look for its UserControls, not find them, and throw a 404.
Thanks all for the sympathy. Sorry to waste your time. Hopefully this will at least help the next guy who fat-fingers a deploy script and gets a non-helpful error message.
Maybe you've already done this, but as you stated you had been recently working on those files, I would start by verifying that the links to the offending pages are correct in the source - check that their declared path is (works out to be) indeed valid. I try and make all links relative with Server.MapPath or something similar, but occasionally one slips my mind.

Resources