We have been given a project by another developer that will not compile because it says none of the page controls have been declared in the VB code. In 2003, control declarations were plainly visible at the top of the VB code. Now they seem to be hidden, using partial classes, I think. But where can we find them? Is there some setting in .NET that will reveal them? Are they stashed in some file with a different name name from the web page form referencing them?

Control *registrations* for ASP.NET pages can be found in the page itself (<%@ Register... %>) or in the web config file (I believe in the system.web/pages/controls element).

If the program won't compile due to missing type references then you may be missing some required files or assemblies.

-Peter

Thanks, but I did not mean *registrations*. I'm talking about:

Protected WithEvents cmdDelete As System.Web.UI.WebControls.Button
Protected WithEvents cmdCancel As System.Web.UI.WebControls.Button

Sorry for using the wrong term, but I don't know what else to call these but *declarations*. In any case, without them VB cannot reference the page controls. So the question remains, where are whatever these things are called hidden in 2005?

A file doesn't exist as it is generated at Runtime.

Without rehashing data that can be found on the web, check out these articles:
http://msdn.microsoft.com/msdnmag/is...ExtremeASPNET/
http://www.code-magazine.com/article...0609061&page=4

That should help you.

-Doug

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
================================================== =========
.: Wrox Technical Editor :.
Wrox Books 24 x 7
================================================== =========

You are right in this case. These would be declarations, I just wasn't sure without a code example.

Are you getting errors those actual type references? The web project should have an assembly reference to System.Web which contains those types. If not, add it.

What is the exact error message you are getting? If you see something like "You might be missing a reference..." then check the references. If you aren't missing references but are still getting this error then something else is going on. Send us the exact error message if possible.

-Peter

We fixed it. The problem *may* have been caused in part by the fact that we were never given the solution/project files (and just why doesn't VS put them in the same *&^% place as the rest of the project, I wonder?). We ended up creating a new project and included the necessary files and that's when we started getting all these bizarre errors saying the controls didn't exist.

After much hair pulling and gnashing of teeth, we finally discovered that when we added this one particular JS include file, VS was changing the inherits attribute in the page line in the HTML as well as JS class name (in code, not the file name) to match another entirely different class. We verified this by looking at the source before and after it was included in the project, and every time these references were changed without notice or explanation, not to mention obviously in error. It didn't change the inherits or class names on any of the other JS include files, btw. We'd probably have found this sooner if it hadn't been buried in the 1,000+ incorrect "missing control" errors. As soon as we corrected these changes, all the "missing control" errors went away.

Your guess is as good as mine on why this should have happened, but I have noticed that a simple syntax error in a user control, for example, makes VS think the control doesn't exist (even when prior compilations were successful). So, perhaps when it thought the JS class didn't exist, none of the pages including it could be resolved or something. What a PITA!

At this point I'm going to chalk it up as just another of the many VS mysteries and hope it never happens again. Thanks again, MS!

In Visual Studio's defense: It usually puts the Solution file along side the project file. I would say that the party that provided you the project simply didn't provide it to you correctly. There's nothing like inheriting code eh!

Glad you got it worked out.

-Peter

That's not only true, but sadly typical of some of the developers I have to work with. I'd hate to tell you the nightmares I've had porting some other programmers' undocumented code (and I unfortunately have to do this all too frequently because we have programmers all over the US).

But it's unnecessarily complicated by the fact that VS doesn't put the solution in the same location as the code. If it did, you could easily pass the whole project to another developer (or check it into VSS) without having to search the entire HD to find all relevant files. It'll be very interesting to see what's missing when we get new hardware next year and some project files are missing because they were not in the right place to be backed up. I expect the issue that started this thread to rear its ugly head again then.

And in our case, not only does VS put the solution in an entirely different folder, but it's apparently writing something to our profiles as well which are stored on our shared network drives here. VS simply won't start when our network is down. I've been trying to root out all the weird places VS stores stuff to see if I can't force it to work exclusively on my system and in just the places I dictate.

Ron,

One fix that might help you is to change the path of your vsSettings file.

Under Tools -> Environment -> Import and Export Settings is the selector for where your settings file lives. By default this will be your user profile. For network based profiles this will slow down VS big time. Change it to a local path and you should notice a boost in VS startup time and better responsiveness.

In general, keep your projects out of your My Documents folder (uber black hole of performance). I have a "Development" dir in the root of my local drive with a "src" dir under that. Then there's a dir for each source code repository and everything under those mirrors the source control tree. It makes things MUCH easier.

-Peter

Peter,

I see the Imort/Export option, but no place under it where I can edit paths used. Assuming I was meant to edit the exported file instead, I exported the settings. It put them in the C:/VS 2005/Settings folder, which obviously is a local folder, and my current settings file appears to be located there as well. Unless I misunderstood your suggestion, I think there must be something else it's trying to use the network for.