1

There is a pattern in ASP.NET - whenever there is a piece of markup that generates code (like the .aspx/.ascx files in WebForms or .cshtml files in MVC3), these files are dynamically compiled at runtime. aspnet_compiler will produce another assembly for them, which references your code-behind assembly.

This approach seems awkward to me and I don't understand why it hasn't been discontinued already. A much better approach (in my opinion) is like in Winforms or resource files - you have your .whatever file, and then there is .whatever.desginer.cs file. This designer file is created at runtime as you type. When you compile, the compiler doesn't care about your .whatever file, it just takes the .whatever.designer.cs file and produces a single solid assembly.

This provides several benefits:

  • You can inherit your forms from each other, similar to windows forms;
  • You can always see the code that is being generated, possibly adjusting your markup to generate better code;
  • You can easily instantiate strongly typed instances of your forms;

The only benefit I can see from dynamic compilation is that

  • You can change the markup file anytime and don't need to recompile the app.

To be honest, I've often wanted for one of the first three benefits, but never for the last one. Recompiling the app to see your changes isn't that big of a deal. Especially since you have to do it anyway when working with code-behind, where the most of your time will be. And when you deliver your app to the client, you deliver it as a monolithic, precompiled block. When you update, you update everything, not just individual .aspx files - there's no point to.

So... why is it like this? What am I missing?

Vilx-
  • 104,512
  • 87
  • 279
  • 422
  • @Vilx, I've gone througn about 30 of your questions and the reason to why people might not answer your questions is that you give to much information, it's pretty much as reading an essay. I am not trying to be rude or trying to tell you how you should roll. But an advice is to write less text, get the point out earlier and you will most certainly get More answers and hopefully better ones. Good luck. – Filip Ekberg Feb 17 '11 at 15:00
  • @Filip Ekberg - I always try to give as much info as possible. Sometimes, when I feel that I can, I split it up in "Short question" and "Long explanation". I don't want to end up trying to solve the wrong problem, just because I've figured out everything myself except one little part - the one which doesn't make any sense. But, OK, I'll try to be more concise. – Vilx- Feb 17 '11 at 15:12
  • possible duplicate of [How do you put an entire asp.net website into one dll?](http://stackoverflow.com/questions/856453/how-do-you-put-an-entire-asp-net-website-into-one-dll) – NotMe Feb 17 '11 at 15:48
  • marking as dupe based on comments to answers below: another potential: http://stackoverflow.com/questions/222276/how-do-i-compile-an-asp-net-website-into-a-single-dll – NotMe Feb 17 '11 at 15:48

2 Answers2

2

It sounds like you are referring to an ASP.Net Website. An ASP.Net Web Application is like an ASP.Net Website, but uses .designer.cs files and produces a single assembly.

See ASP.NET Web Site or ASP.NET Web Application?.

Community
  • 1
  • 1
mellamokb
  • 56,094
  • 12
  • 110
  • 136
  • I agree, it is nothing more than personal preference and VS lets you choose which one you prefer. – Biff MaGriff Feb 17 '11 at 14:37
  • Even in this case the aspx/ascx is compiled on the server. What is more as far as I know MVC projects only work as web applications – Stilgar Feb 17 '11 at 14:38
  • No, this affects web applications too. The designer.cs file in a typical (non-mvc) ASP.NET web application gets only the definitions of member controls. The actual rendering code is inaccessible to you, unless you like to crawl through a labyrinth of guid-named files in ASP.NET Temporary Files folder. In a MVC3 app (which I'm working now) the .cshtml files don't even get a designer.cs file. – Vilx- Feb 17 '11 at 14:43
  • Also, even when you precompile an asp.net web application, and even after you use aspnet_merge, you still get two assemblies (DLL files) - one with your codebehind, the other with all the .aspx/.ascx autogenerated code. – Vilx- Feb 17 '11 at 14:44
  • I've never had any of these problems with web application projects. What am I missing? – mellamokb Feb 17 '11 at 14:49
  • Try inheriting one web form from another. Not just the code-behind, but the whole markup 'n stuff. – Vilx- Feb 17 '11 at 14:59
  • @Biff MaGriff: it is much more than personal preference. There are a lot of things "web sites" do that impede team development. Which is the #1 reason for "web application" projects. – NotMe Feb 17 '11 at 15:01
  • @Vilx: That's what master pages are for – NotMe Feb 17 '11 at 15:01
  • @Chris Lively - Inherited forms (like in winforms) can be inherited on many levels. Masterpages only work on one level. In addition, masterpage doesn't know anything about its child page. When I inherit a form, I often want to hide some controls too, not just add more. – Vilx- Feb 17 '11 at 15:03
  • What about user controls? Can you provide a use case where you inherit a form? I think there are ways to accomplish all these things, it's just modeled differently in the web because of how the web works compared to a desktop application. – mellamokb Feb 17 '11 at 15:08
  • User controls allow including each other, but not modifying, unless you explicitly code that. The use case for this can be found in the business world where there are all kinds of documents, and sometimes a document is really just a special case of another document, or at least very closely related to it with but a few changes here and there. Sorry, I don't have an example handy right now, but the situation comes up every now and then. – Vilx- Feb 17 '11 at 15:14
  • One more reason is that you can't make your codebehind classes internal if you want to use them in your form markup. This is more relevant to MVC. It would pretty much make sense to me to make all the helper classes internal, but they have to be public, otherwise the DLL with the compiled cshtml won't be able to use them. – Vilx- Feb 17 '11 at 15:15
  • Fair enough. Sorry I couldn't give a better answer. Might be something to direct to the developers at Microsoft. – mellamokb Feb 17 '11 at 15:16
  • @Vilx: a user control is no different than a regular winforms composite control. In winforms you'd have to code the ability to support hiding parts of it has well. – NotMe Feb 17 '11 at 15:19
  • @Chris Lively - you do agree that in winforms there is a difference if a usercontrol includes another usercontrol, or inherits from it? – Vilx- Feb 17 '11 at 15:23
  • @Chris Lively Regardless, the question has a subjective slant. The technology was designed that way for people to use if they chose to. Use it or do not. I think this question is on the lines of "Why isn't HTML compiled?" – Biff MaGriff Feb 17 '11 at 15:41
  • @Biff, @Chris - I'm sorry if it has come out so. Yes, it is a bit of a rant, but I also was wondering if there perhaps is some significant benefit that I'm overlooking. – Vilx- Feb 17 '11 at 15:44
  • @Vilx Personally I love using website projects for RAD. I can whip up a fully functioning prototype and not worry about security, DAL, BLL, etc. in no time at all. Not having to recompile means I can change my code and hit F5 in the browser and quickly see if my changes did what I thought they would do. – Biff MaGriff Feb 17 '11 at 15:49
1

One thought that comes to mind is that the primary difference between winforms and webforms has to do with the common development model.

Namely, there is a whole class of developers and designers who work strictly in html/css/javascript. They use a host of tools ranging from notepad on up to competing development products to build these pages.

Further, in the case of WinForms, MS has complete and total control of what can make up a form. Any controls that can be dropped on it have to descend from their specified code.

However, with HTML they don't have this same level of control. Spec changes occur out of sync with VS releases, additional features are added that are browser specific, etc. In short, they can't guarantee that a particular element in the HTML file is a valid element at all. All they can hope for is that whatever is sent was done so on purpose and that the browser knows how to deal with it.

Now they have tried to implement a model that provides visual inheritance. It's called "master pages". However, I believe the only tools that properly work with master pages are VS and Expression. Getting the other vendors to go down this path would be nearly impossible. Also, they've added the concept of "nested master pages" such that you can get multiple levels of inheritance out of them.

The code behind model helps to implement non-visual inheritance allowing people to completely revamp page processing (hence how MVCx works).

Which leaves us with the parts that MS does know about. Obviously they do have a .designer file which backs the .aspx pages. This designer file maintains the server control list that is accessible by the code behind. You could add runat="server" to every regular element in an html page (excluding artifacts like css) but this would increase the amount of processing required for the page.

To sum up, I think they've picked the best model they could for web development given the lack of control they have over how the web works. Other vendors have tried similar paths (e.g. Adobe Contribute, previously by Macromedia). I believe some of those even predate MS's model.

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • 1
    All this doesn't conflict with what I want to do. Namely, have it all compiled in a single DLL file. Behind the scenes all your markup gets converted to C# code anyway. Why can't you access it? Why does it live in a separate DLL and cannot access your `internal` data? – Vilx- Feb 17 '11 at 15:20
  • @Vilx: If that is truly what you want to do then this is a duplicate question: http://msdn.microsoft.com/en-us/library/bb397866.aspx – NotMe Feb 17 '11 at 15:47
  • aspnet_merge still produces two DLLs - one for my codebehind, one for all the ASPX/ASCX/CSHTML files. I can go the extra step and use ILMerge on them (as you've suggested above), but that doesn't at all address the core problem - that when compiling, these two worlds are separate. I still cannot, for instance, use `internal` helper classes from my ASP.NET MVC Views. And I cannot manipulate the view classes from codebehind. – Vilx- Feb 17 '11 at 19:17
  • @Vilx: If this is the "core problem", then perhaps that should be the question you are asking. The question as asked was (and I'm paraphrasing) what additional benefits are there to late compiling the aspx pages. This has been answered. – NotMe Feb 17 '11 at 21:08
  • You misunderstand me. What I'm trying to say is that I only see drawbacks from the late compiling. You're trying to justify saying that "here is a way to eliminate those drawbacks" to which I'm replying "no, it doesn't". There is just one question and your paraphrase is correct. The rest is just unfortunate divergence. – Vilx- Feb 17 '11 at 21:21