Visual Web Developer 2005 Express

Re: Pre-compilation anywhere

BradleyB — Fri, 02 Dec 2005 19:02:31 GMT

I think the problem you're runing into is with the sub project. Web Site projects in VS05 represent an entire site. You can have sub-webs but they must really sub-webs in the IIS metabase not just a sub-projects. The App_Code folder is a special ASP.Net 2.0 folder that can only exists at the root of a Web Site applicaiton. It is similar to bin in that way. The class form the sub projects App_Code folder is never being compiled by ASP.Net.

To work around this you can either move the class from the sub-project App_Code folder to the root App_Code folder or setup the sub-project as sub-web in the IIS metabase.

Hope this helps, Brad.

Re: Pre-compilation anywhere

ryan.reid — Fri, 02 Dec 2005 00:34:10 GMT

I've spent the last 3 days on this and I really don't see a workaround. Our architecture requires that you dynamically load UserControls. This seems to work only if the master page knows about the child control.

I've got a simple set of projects that doesn't work that has me absolutely astounded:

Here's the issue, takes me about 2 mins to reproduce:

- I have a terribly simple project called Master that is a web project.

- I have a subproject in a subfolder of Master called "subproject"

- The subproject has a control named "ChildControl.ascx"

In the master project's single page (Default) I have this code:

public partial class _Default : System.Web.UI.Page {

protected void Page_Load(object sender, EventArgs e)

{

UserControl uc = (UserControl)LoadControl("subproject/ChildControl.ascx");

}

In the subproject's ChildControl.ascx I have this code:

public partial class ChildControl : System.Web.UI.UserControl {

protected void Page_Load(object sender, EventArgs e)

{

string x = SharedCode.SayHello();

}

In the subproject I also have a class with a single static method called SayHello(). This class is in the App_Code folder of subproject.

When I run this project, I get this error:

Compiler Error Message: CS0103: The name 'SharedCode' does not exist in the current context

But of course it DOES EXIST.

I can't believe that this isn't possible. All I want to do is to use code IN THE SAME PROJECT (ChildControl's App_Code folder) with a static method.

Re: Pre-compilation anywhere

rstrahl — Sat, 22 Oct 2005 19:55:53 GMT

No offense Meson, but you're missing the point.

This has nothing to do with what the user sees. This has to do with architectual issues of how an application is built - not an external way to redirect to other pages. Some applications, like portals and CRM systems specifically require that components are loaded dynamically, and this has nothing to do with how users navigate to a particular page or what the URL looks like. What it has to do with is how the content of that page is loaded and that's what this thread and the complaints are about... specifically since this behavior has changed and has broken a common usage pattern for many developers.

+++ Rick ---

Re: Pre-compilation anywhere

Meson — Sat, 22 Oct 2005 08:27:42 GMT

I am one of those peopel that like how .net 2 works.

Most of my web forms don't need to talk to each other. If they do, all they need to do is pass a number, which is easy to send on a query string and validate. This also makes the queries bookmarkable, which makes the application user friendly.

The separate assembles method is similar to how the open source industry works: do one thing well and pass the result to next in line by script. This is the best way to look at web applications, since that is how the end user sees them. When a user ccomes to a 50 page site, he/she sees 50 different and separate applications, not one, and will treat the site as 50 applications. Writing web sites to conform to this mentality makes for faster applications.

Some of the applicaiton I read from posts on thsi site sound like they are in serious need of redesign. They seem to designed as Windows programs, which doesn't cut it a cross-platform environment such as the internet.

Re: Pre-compilation anywhere

mbund — Mon, 17 Oct 2005 17:28:18 GMT

I just re-read what I posted and I should have been more clear. AFAIK, there is no way to maintain a single assembly compilation model with VS05 and ASP.NET 2.0 that I know of.

Re: Pre-compilation anywhere

mbund — Mon, 17 Oct 2005 17:27:16 GMT

AFAIK, there is no way to do this with VS05 or ASP.NET 2.0.

Re: Pre-compilation anywhere

barwickl — Mon, 17 Oct 2005 08:05:18 GMT

Yeah, in my case adding a reference to each page would solve the problem but it doesn't feel like the right thing to do. This is not an application I'm migrating either but it's a model which I found worked in NET 1.x. It feels awkward to insert and maintain a list of references in every page. As you'll appreciate, if I need to generate links to 10 different pages using my technique, I will be required to reference each of the 10 pages. This just worked in NET 1.x.

This is a breaking change between framework versions and I'd hope there was some way to maintain the previous (single assembly) behaviour. Can anyone tell me if there is a way to do this? I suspect not as we no longer have web project files and several other people seem to have ran into problems setting default namespaces, etc.

Re: Pre-compilation anywhere

mbund — Fri, 14 Oct 2005 18:41:27 GMT

Just checking, but wouldn't adding a Reference directive to your aspx page allow your static method to work (I assume this is a code-behind to code-behind reference)? If so, it seems like a simple fix (and one that is usually caught and fixed by the latest web project migration wizard).

Re: Pre-compilation anywhere

barwickl — Mon, 10 Oct 2005 11:57:13 GMT

To avoid hardcoding URL's and querystring parameters in my pages I would often add static methods with parameters to a page. For example, ShowCustomerDetails(customerID As Integet) which returned a Url with query string parameters ("/CustomerDetails.aspx?customerID=123"). This allowed standard interfaces to be developed between pages. I'd use the static method to set the NavigateUrl of hyperlinks, etc. I was quite pleased with this solution as it allowed type safety of parameters and allowed parameter names, default values, etc to change without touching any referencing pages.

As 2 pages can no longer 'see' each other this is now broken in Net 2.0. This is just another example of the pain which is the new compilation model.

The ASP team can give us any number of workarounds to the new problems introduced but the fact is they are problems which should have never been created. I've read ScottGu's justification of the changes and the removal of the web project file but the fact is I'm not seeing any of the perceived benefits, just being frustrated at the things which no longer work in 2.0.

Time and time again, we're seeing MVPs and other experts in the community criticse the new model but the ASP team don't seem to want to listen. Where are all the advocates of the new model? I certainly don't see any outise the ASP team.

The new features in Whidbey bring a huge amount to the ASP web platform but the changes to the compilation model/lack of a project file seem to be a huge step backwards.

Re: Pre-compilation anywhere

Kressilac — Tue, 27 Sep 2005 23:51:51 GMT

I'm currently developing a large site and I can tell you that the "performance gains" of multiple assemblies is not as great as advertised. We currently have about twenty directories and some of them have upwards of 50 aspx pages. Each page typically has a databound grid view, two databound edit views and at times 1 - 10 child grid views on a detail view. With the amount of data that we display on the application, a CRM application for Auto Dealerships, compile times have become a problem even with the new enhancements.

Our experience has shown that the compiler is very picky about which files have been touched and how they affect other files. This is perhaps a result of all the app_Code classes that make up our business layer being compiled into one assembly. Touch the a single file in that directory and the entire application recompiles.

Our editing has show sporadic support for editing on the fly. Often times a single attribute change to the markup of an aspx page causes the entire application to recompile which at this point forces the rerun of the application to timeout. It would be nice if the built-in web server preserved sessions state and httpcontext while the compiler was working its magic. As of now we end up recompiling about once every three changes to a page. Code behind changes increase the rate of site recompile and touching anything common invalidates the entire common layer.(i.e. app_Code, app_Themes, master pages, bin dlls)

At this time, I'm not convinced there is a big performance improvement over the old 1.1 way of doing things. On paper, sure and in marketing yes it is there but in the real world its just not as visible. A small upgrade in developer ease really.

Derek Licciardi

Re: Pre-compilation anywhere

swildermuth — Mon, 26 Sep 2005 22:05:53 GMT

I agree with Rick. My problem with it is *not* a migration issue... I am working on a new site and the <% VirtualReference %> idea seems to be hacky, and the idea of a post-build step to build into a single assembly is a hack. I understand the motivation for this *feature* but it should be an option, not the default (IMHO).

Re: Pre-compilation anywhere

mbund — Mon, 26 Sep 2005 21:51:28 GMT

My apologies for not being clear. I meant the set of VS05 web project changes (not just the use of multiple assemblies) allow easier web development as well as performance improvements. The URL I posted was for Scott's justification of that statement.

Thanks,

Re: Pre-compilation anywhere

rstrahl — Mon, 26 Sep 2005 21:42:03 GMT

Michael,

With all due respect to Scott, but what Scott describes in that post is a hack! It's a workaround for a design problem that many people have pointed out very early on in the product cycle and have been ignored by the ASP.NET team.What's interesting to me is that the people that are complaining about this most are many of the gurus who supposedly know how to take best advantage of the tool - that's always a bad sign when your most loyal supporters end up being the loudest for criticizing a feature.

This isn't the last you're going to hear about this problem either - once ASP.NET ships and more developers will actually build real applications with it you will see many more developers run into this issue.

Part of the problem too is that even for new development this will be a huge issue, because once you get to the point where you need to dynamically drop controls there aren't a whole lot of workable options to do it and you're stuck.

+++ Rick ---

Re: Pre-compilation anywhere

swildermuth — Mon, 26 Sep 2005 19:59:15 GMT

I've been told the "performance improvement", but since no compilation is happening at runtime in most large sites, I don't see multiple assemblies as being a performance improvement. Perhaps at development time. (I have read on Scotts blog about a new tool to allow compilation to a single assembly for deployment.)

But to understand what you said, how does multiple assemblies help "make it easier to develop web apps"? Easier for the ASP set who want do drop their code on a server and have it auto-compile, sure. But again, for most enterprise-sized applications this is a security risk and encourages the black days of developers having access to the web servers to fix issues. This certainly feels like a step backwards, not forwards.

Re: Pre-compilation anywhere

mbund — Mon, 26 Sep 2005 15:54:47 GMT

The change to use multiple assemblies is just one of many changes in the web project system to improve performance and make it easier to develop web apps. If you have not done so already, you should check out ScottGu's blog post on the subject at http://weblogs.asp.net/scottgu/archive/2005/08/21/423201.aspx

Thanks,