 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / General / October 2007ASP .NET 2.0 Unanswered questions...
I've asked this before, but not gotten any clear answers, so I'd figure I'd try again. I am an experienced ASP .NET 1.1 developer and I understand the differences between an ASP .NET 2.0 "Web Site" vs an ASP .NET 2.0 "Web Application" (among other things, all compiled code placed in several assembly files vs. one assembly file). Here are my 2 questions: ASP .NET 2.0 "Web Application Project" ============================= In ASP .NET 1.1, when you use a DataAdapter (say with the DataAdapter Configuration Wizard), you'd be able to see all the wizard's generated code in the code-behind and perhaps tweak it. In ASP .NET 2.0 Web Application Project, if I use a TableAdapter and configure it using the designer, I can't find any code (yes, I know to look in the designer.vb file, rather than the code-behind) for it. Where is the code that makes all this new cool ASP .NET stuff work with some configuration? I know I can't just see the underlying code for the class, but I want to see the code for the instance. Where is it?! ASP .NET 2.0 "Web Site" ================== Where are the compiled assembly files placed? I don't see them anywhere in my site's directory structure. No offense, but please only respond if you *know* the answers, not if you just have suggestions on where I *could* look. Thanks, Scott I will attempt to answer your questions here without upsetting you too much as I'm pretty sure I "know" the answers to your questions: 1, Where's the data adapter code? In 2.0, in the web application project, XSD designers including data adapters are considered partial classes. They are also compiled and the code is generated for them at run-time. Therefore, there is no code to view. If you want to override a method or property, add attributes, directives or change the way those adapters work or map outside of the designer, simply create a new code file in your App_Code directory and define a class (in your dataset adapters namespace) called the exact same name as the data adapter and mark it as partial (e.g. public partial class MyDataTableAdapter), no need for inheritence, this will already be set up for you, you can however add interfaces if you wish. Then you will notice when typing "override", you are provided with the virtual methods and properties from your data adapter and can manipulate the class without having to "inherit" from it. 2, Where have all the assemblies gone? C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\%app name%\ and then followed by intertwined assembly directories and cache created by the runtime, e.g. agentonline\88ab2d2c\588ae2f5\ and then you will find your assemblies such as App_Browsers.dll, App_Code.dll, App_Web_wu_bfbz-.dll, etc. Hope this helps you out. Regards, Chad > I've asked this before, but not gotten any clear answers, so I'd figure > I'd try again. [quoted text clipped - 30 lines] > > Scott It seems to me that by having to generate the code for, say a TableAdapter at runtime, the application execution would be slowed. Do you mean that this code is generated at build time and then added to the assembly? Thanks Chad! >I will attempt to answer your questions here without upsetting you too much >as I'm pretty sure I "know" the answers to your questions: [quoted text clipped - 63 lines] >> >> Scott Yes, that's what I meant. Sorry. > It seems to me that by having to generate the code for, say a TableAdapter > at runtime, the application execution would be slowed. Do you mean that [quoted text clipped - 69 lines] >>> >>> Scott One other point worth mentioning Scott. There are two different ways of deploying an ASP.NET 2.0 web site - copying and "publish" There is a tool for copying the web site in VS2005 which is a very convenient way to deploy if you want to do incremental updates. It does mean that no DLL assemblies are uploaded but caching on the web server should compensate on a reasonably busy site where the traffic is not spread among too many different pages. The publish option does create a deployed site in a manner very similar to the "release" version of ASP.NET 1.1 (i.e. a bin directory) but according to Microsoft this method is not necessary unless it is a very large site where traffic is spread over a lot if different pages. HTH > Yes, that's what I meant. Sorry. > [quoted text clipped - 73 lines] > > - Show quoted text - Thanks Phil. > One other point worth mentioning Scott. There are two different ways > of deploying an ASP.NET 2.0 web site - copying and "publish" [quoted text clipped - 105 lines] >> >> - Show quoted text - question 1: the fundamental change with .net 2.0 was implementation of partial classes. this changed the way designers worked. in 1.1 they generated code il code that was then converted to the language of choice, so that the source could be edited (sometimes by the designer only) if needed. in 2.0 the designer just produces il code, because it can be merged with a language source file to produce one class. there are no hidden source files, because they are not created anymore. this is way you can not find the tableadapter code. the only way to see the designer source code is to find the assembly it ended up in (easier if in the app_code folder or seperate project, as only one assembly is created) and recompile it (or use reflector). question 2: .net 2.0 (just like 1.0) creates temp folders that the web site is copied to and compiled. where these folders are depends on configuration but the default is under the .net installation folder. just like 1.1 the folder are really a hashed set, with a folder for each assembly and rev (say a recompiel of one page). also just like 1.1 a assembly is created per page (for both web sites and web applications), so finding the folder for the desired page is a little work. you can precompile the site to a work folder with the aspnet_compiler, and its easier to find stuff, because all assemblies are in the bin folder. -- bruce (sqlwork.com) > I've asked this before, but not gotten any clear answers, so I'd figure I'd > try again. [quoted text clipped - 30 lines] > > Scott > also just like 1.1 a assembly is created per page erm .. unless I'm missing something serious..... thats just wrong.. My understanding is that this is now true for a "web site" in ASP.Net 2.0 but was not true for ASP.Net 1.1 and is not true for ASP.Net "Web Applications" "Web applications" and "Web Sites" are 2 different project types in VS 2005. I thought that Web Applications followed the Old rules(1 Dll per project) and that the Web Sites followed the alternative view of 1 dll per page. This was originally the only web project type in VS2005 and Web Applications were then added back by popular demand via a ctp (or something like that) and then later made more concrete via SP1. Did I miss somthing? -- Rory >> also just like 1.1 a assembly is created per page >> > erm .. unless I'm missing something serious..... that's just wrong.. It is wrong. > My understanding is that this is now true for a "web site" in ASP.Net 2.0 > but was not true for ASP.Net 1.1 and is not true for ASP.Net "Web > Applications" That is correct. > "Web applications" and "Web Sites" are 2 different project types in VS > 2005. Correct. > I thought that Web Applications followed the Old rules(1 Dll per project) > and that the Web Sites followed the alternative view of 1 dll per page. > This was originally the only web project type in VS2005 and Web > Applications were then added back by popular demand via a ctp (or > something like that) and then later made more concrete via SP1. Right again. > Did I miss somthing? Not really, though Web Deployment Projects add some extra options...  SignatureMark Rae ASP.NET MVP http://www.markrae.net >> Did I miss somthing? >> > Not really, though Web Deployment Projects add some extra options... Cheers man. For a moment there, I thought I'd slipped into a parallell world or something. It's been the type of week where that might have explained a lot of things :) -- Rory 1 dll per page: it is correct. the confusion most people have, is they look at the source folders. a web site does not run from there. asp.net copies the folder to tempormay folders, then compiles it. how much compiling is required depends whether the site was precomplied. even a precomplied site needs to be jit'd. in a web application the code behind files are compiled into one assembly placed in the bin folder by visual studio via the proper language compiler. but the asp pages still need to be compiled into partial classes. for this visual studio uses the aspnet_compiler for final compilation. this gives visual studio few options, as it has to follow the apnet_compiler rules: where code is located, where dll are located, what assemblies are produced. the .aspx, .acx and .master files are compiled into assemblies with hashed names. actually depending on compiler options some batching (just like in 1.1) can occur where several aspx pages are compiled into one assembly. a small site can have all pages compiled into one assembly and user controls into another, but you can not count on this. the batching behavior is what leads to reference bugs which are only seen in production. if two pages reference each other and end up in the same batch, the compiler is happy, but if they end up in different batches then a compile error occurs. currently web application are kind of hacky, because visual studio has to hide the code behind files from the aspnet_compiler or they would be included twice. it does this by creating yet another temporary folder system to do compiles in. this is because unlike other compilers which you can give a list of files to compile and their references, the aspnet_complier compiles a folder. so in general, a web application will produce more final assemblies then a web site. also a web application will take a little more disk space. this is because at runtime, a folder is created for each page and all referenced dll's are copied to the folder. the web application codebehind dll will be duplicated in each assembly folder. the asp.net compilation model is very complex due to its goals of allowing page recompiles without recycling. it complicated due to the fact that .net does not allow unloading of assemblies, except via domain unload (recycle in asp.net). this means to recompiel a page, a new dll must be created with a new name, then loaded into memory. you don;t want these dll's to be too large, because the virtual memory is not given up until the recycle. for example, on a 32bit machine if the page assembly was over a gig, then a recompile of the page would automatically cause a recycle, because the load of the new page would cause an out of memory error (only 2gb of memeory is avaiable in user space). this is extreme, but assembly memory usage is competing with in-proc session memory. -- bruce (sqlwork.com) >>> also just like 1.1 a assembly is created per page >>> [quoted text clipped - 25 lines] > > Not really, though Web Deployment Projects add some extra options... >1 dll per page: 1 DLL per web application. > it is correct. No it isn't. > in a web application the code behind files are compiled into one assembly > placed in the bin folder by visual studio via the proper language > compiler. Indeed - one DLL. > but the asp pages still need to be compiled into partial classes. That's correct, but irrelevant to the number of DLLs created. > for this visual studio uses the aspnet_compiler for final compilation. Again correct, but again irrelevant - a web application will compile into one assembly. > so in general, a web application will produce more final assemblies then a > web site. Incorrect. SignatureMark Rae ASP.NET MVP http://www.markrae.net Bruce.... ...can you point to any references to back this up? Whilst I am interested in all versions of ASP.Net, I would be very interested for you to provide a reference which suggests that an ASP.Net 1.1 application produces 1 assembly per page as I do not believe this is the case. Likewise I have not seen this behaviour for ASP.Net 2.0 "Web Applications" All shadow copied assemblies appear to be literally copies of those found in a Bin directory of the Web Applications source. Also I believe that with the exception of NGen (whose native images are ignored by ASP.Net 1.1 anyway.) Jit compiling does not produce further assemblies as it is an in-memory process only. Thanks -- Rory > Whilst I am interested in all versions of ASP.Net, I would be very > interested for you to provide a reference which suggests that an ASP.Net > 1.1 application produces 1 assembly per page as I do not believe this is > the case. It isn't... > Likewise I have not seen this behaviour for ASP.Net 2.0 "Web Applications" Of course you haven't... SignatureMark Rae ASP.NET MVP http://www.markrae.net My previous reply to Bruce regarding his interesting claims was merely the politest version of the original text i came up with. I hasten to add that at no point did I think of writing anything which I would have wanted to cause upset. we're talking things like.... ----------------------------- Bruce man you're smoking some good sh.t. ----------------------------- ..Or.. ----------------------------- I call Bullshit ----------------------------- The thing is they just seemed a bit antagonistic. However I would like to thank Bruce and yourself because I had not discovered any of the Web Deployment Project /ASPNet_Compiler references before they were mentioned by yourselves. So all in all it's been very interesting so far.... I am still interested to hear bruces take on things..... It's amazing how language barriers etc can lead to misunderstandings of various kinds. Perhaps Bruce does not mean what he appears to be saying. :) -- Rory in both 1.1 and 2.0 there are two types of source files. code behind usually written in c# or vb, and asp.net source files. version 1.1 of asp.net in order to support inline server script (or asp.net codebehind with no visual studio support), generated source code for the page, then called the desired compiler to build a dll. this was done on the first request to the page. the source file was produced in a temp folder (and an actual compiler script), and after being built the assembly was loaded into memory. this also required all dll's in the bin folder be copied to the temp. a visual studio project would build the codebe in version 2.0, because of partial classes, the aspnet_compiler converts aspx pages to il directly, (actually so did 1.1, but it used the .net codedom library to convert il to source code). version 2.0 has a bunch of compiler options, (if you look in your msbuild scripts you can see the aspnet_compiler options you are using). you shoudl read the apnet_compiler documentation to get an idea of how it works. you can also look in your deployment project. if the aspx pages are all empty (no source) then your site was precompiled for all the aspx pages and has been batched into dll's (again depending on compiler switches). if they contain source code, then they will be compiled at runtime on first page request much like 1.1 again in version 2.0 the only difference between web sites and web application is the handling of the code behind files compilation (whether the aspnet_compiler call the language compiler or msbuild) and in the case of a web applications the existence of a project file. there is no difference in how the aspx pages are compiled. in either case you should use deployment projects to build a deployment folder. even if you use only notepad, and the aspnet_compiler, to build a production web site, you can get the same results as visual studio. again the main benefit of web applications (to the developer) is not having to define formal interfaces in the app_code folder for pages to call each other (this is what broke most 1.1 apps trying to move to 2.0 and drove MS to release web application projects). i personally feel defining interfaces is a better practice (see interface design pattern), but it is more work. in any case disk space is cheap and you shouldn't worry too much about how many dlls are produced. ps. looking in vs2008, with a web application i can see no way with visual studio to do a full precompile of the aspx pages like you can with a website. you could still update the msbuild file manually to do it though. i'll check with vs2005 when i get chance to see if it has the same limitation. -- bruce (sqlwork.com) > Bruce.... > [quoted text clipped - 14 lines] > assemblies as it is an in-memory process only. > Thanks But Bruce, you seem to be talking about the compile process more than the simple fact that in 1.1, only one assembly file is produced. It is *possilbe* to deploy pages without the assemblies and let that process happen on the fly. But, when producing assemblies ahead of time, there would just be the one. > in both 1.1 and 2.0 there are two types of source files. code behind > usually written in c# or vb, and asp.net source files. [quoted text clipped - 71 lines] >> assemblies as it is an in-memory process only. >> Thanks You're saying that VS 2003 produces a single assembly. Bruce is saying that when VS 2003 isn't used, more than 1 assembly is produced. I.o.w., using the same 1.1 .Net Framework version will produce either one assembly in the bin dir...or no assembly, depending on whether you use VS 2003 or not. Did you know that you can *also* pre-compile ASP.NET 1.1 applications ? In effect, that prevents the "first-compile" lag when deploying 1.1 apps. See : http://www.daveranck.com/DesktopModules/XMod/PrintPreview.aspx?xmdata=9qX4dagsEY BkLFPpV%2BJTvBiObAU1SomS3KLMg%2FuybVrA9YICclotYZOJ5rTbxFbwNYKdc5QG96uQVGIVKnqYDd V0c0Z3bI%2FK2zjiZf30S5o%3D Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== > But Bruce, you seem to be talking about the compile process more than the simple fact that in 1.1, only one assembly > file is produced. It is *possilbe* to deploy pages without the assemblies and let that process happen on the fly. [quoted text clipped - 56 lines] >>> compiling does not produce further assemblies as it is an in-memory process only. >>> Thanks > You're saying that VS 2003 produces a single assembly. > Bruce is saying that when VS 2003 isn't used, more than 1 assembly is > produced. He has also said in this thread that VS 2003 produced multiple assemblies (one for each page). > I.o.w., using the same 1.1 .Net Framework version will produce either one > assembly > in the bin dir...or no assembly, depending on whether you use VS 2003 or > not. Yes. > Did you know that you can *also* pre-compile ASP.NET 1.1 applications ? > In effect, that prevents the "first-compile" lag when deploying 1.1 apps. Yes. > See : > [quoted text clipped - 95 lines] >>>> process only. >>>> Thanks re: !> He has also said in this thread that VS 2003 produced !> multiple assemblies (one for each page). He was talking about a different kind of assembly: JIT-compiled assemblies. Those go in the Temporary ASP.NET Files directory. In essence, you were both right...but were talking about different things. Sometimes, semantic problems are more complicated than programming problems. <chuckle> Btw, I appreciate/value your regular contributions here. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> You're saying that VS 2003 produces a single assembly. >> Bruce is saying that when VS 2003 isn't used, more than 1 assembly is produced. [quoted text clipped - 5 lines] > > Yes. >> Did you know that you can *also* pre-compile ASP.NET 1.1 applications ? >> In effect, that prevents the "first-compile" lag when deploying 1.1 apps. [quoted text clipped - 76 lines] >>>>> compiling does not produce further assemblies as it is an in-memory process only. >>>>> Thanks > re: > !> He has also said in this thread that VS 2003 produced [quoted text clipped - 3 lines] > assemblies. > Those go in the Temporary ASP.NET Files directory. Yes, but he said that this assembly was created one per page, and they aren't. > In essence, you were both right...but were talking about different things. > Sometimes, semantic problems are more complicated than programming [quoted text clipped - 128 lines] >>>>>> process only. >>>>>> Thanks re: !> Yes, but he said that this assembly was created one per page, and they aren't. They are. Look in the ASP.NET Temporary Files directory for any ASP.NET 1.1 app you have running...and verify that. You'll also find an assembly for each component in the "assembly" sundirectory of your app. In fact, in my ASP.NET 1.1 discussion board subdirectory, there's 54 assemblies in several subdirectories of the app's .Net Framework 1.1's ASP.NET Temporary Files directory. That same application has 7 assemblies in the /bin subdirectory ( it uses six component dll's, over and above the compiled project's dll... ) Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> He has also said in this thread that VS 2003 produced [quoted text clipped - 113 lines] >>>>>>> compiling does not produce further assemblies as it is an in-memory process only. >>>>>>> Thanks > re: > !> Yes, but he said that this assembly was created one per page, and [quoted text clipped - 12 lines] > uses six component dll's, over and above the compiled project's dll... > ) I can find no evidence in any of my long running ASP.Net 1.1 applications, of any assemblies that do not have an exact mapping either to a referenced Assembly (Log4Net.dll for example) or to a project within the solution from which the Application was built. Again I ask for official documentation which refutes this. Stating that you have some assemblies on your machine really doesn't help your case. I suggest again that the multiple assemblies found are instead the result of much shadow copying. -- Rory re: !> Again I ask for official documentation which refutes this. Why don't you present "official documentation" which supports it ? re: !> Stating that you have some assemblies on your machine really doesn't help your case. Except that they're there...which must mean *something*. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> Yes, but he said that this assembly was created one per page, and [quoted text clipped - 12 lines] >> uses six component dll's, over and above the compiled project's dll... >> ) > I can find no evidence in any of my long running ASP.Net 1.1 applications, of any assemblies that do not have an exact > mapping either to a referenced Assembly (Log4Net.dll for example) or to a project within the solution from which the > Application was built. > Again I ask for official documentation which refutes this. > Stating that you have some assemblies on your machine really doesn't help your case. [quoted text clipped - 3 lines] > -- > Rory > re: > !> Again I ask for official documentation which refutes this. [quoted text clipped - 4 lines] > doesn't help your case. > Except that they're there...which must mean *something*. Juan, I think Scott has pointed me at a page which might explain things. See my reply to him for details. However I suggest "again" that ""they're there on my machine" is sufficient evidence for all those of us that can see your machine... They are not there on my machine or on Scotts (apparently) However as I said there appears now to be some indication of why. Could you possibly chime in against my other rply and indicate how you have created a 1.1 web app where you have aspx pages not represented by classes in your main assemblies as I think it is this that is causing this side effect. I have no such pages in my applications and I feel this is why Myself and scott have missed this. Thanks for your contributions (you too Bruce). It's always nice to learn something new. It would just be nice now to know under what circumstances this is useful :D -- Rory > However as I said there appears now to be some indication of why. > [quoted text clipped - 5 lines] > I have no such pages in my applications and I feel this is why Myself and > scott have missed this. This has been covered already though in this thread Rory. *If* you don't compile your pages and just deploy them w/o an assembly, you will get an assembly per page in the temp folder, but I have said (in at least 2 posts in this thread) that this scenario is *not* what I am referring to, yet Bruce has insisted that even when you do use a compiled assembly, you'll still get one per page - which I don't think is correct. -Scott re: !> Bruce has insisted that even when you do use a compiled assembly, !> you'll still get one per page - which I don't think is correct. Bruce isn't the only one saying that. I am saying it, too. For a moment I thought that maybe whether codebehind was used, or not, would be the key difference, but the 1.1 app I'm using has both inline code pages and codebehind pages...and still has one assembly per page in the ASP.NET temp files directory. The app is compiled previous to deployment, as are all VS 2003-compiled apps. I should add that the app was written using ASP.NET "best practices", and that a senior member of Microsoft's ASP.NET Development Team ( the team that wrote ASP.NET ) participated in the application's architecture and programming. Are you using the .Net Framework 1.1' SP1 and the Security update for SP1 ? Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> However as I said there appears now to be some indication of why. >> [quoted text clipped - 9 lines] > > -Scott > For a moment I thought that maybe whether codebehind was used, or not, > would be the key difference, but the 1.1 app I'm using has both inline > code pages and codebehind pages...and still has one assembly per page > in the ASP.NET temp files directory. I had also thought that this might be the key difference. I have not been involved in many different projects but have been involved in a particular project since ASP.Net 1.0 One (possibly strange) thing that we have done.... We do not use "Any" Code-inline. Which is to say that all our code is in the codebehind files. This may be different to what you have done and might possibly explain the difference. If not... I would be interested to see the simplest possible example of a webapp which exhibits the behaviour you describe. Thanks -- Rory > One (possibly strange) thing that we have done.... We do not use "Any" > Code-inline. Which is to say that all our code is in the codebehind files. > > This may be different to what you have done and might possibly explain the > difference. The same is true for me Rory. I never use the inline model - always code-behind. > Are you using the .Net Framework 1.1' SP1 and the Security update for SP1 > ? VS 2003 1.1 SP1 fully updated and patched. But, I experienced the same behavior from day one of VS .NET 2003. > re: > !> Yes, but he said that this assembly was created one per page, and they [quoted text clipped - 4 lines] > Look in the ASP.NET Temporary Files directory > for any ASP.NET 1.1 app you have running...and verify that. When I look in the ASP.NET Temporary Files directory for 1.1 apps., I see just one assembly (which is based on the one that exists in my /bin folder). 1.1 is not new to me. I've seen this one assembly behavior over and over for many years now. If I have 100 or 1000 pages in my ASP.NET 1.1 application, there will just be one assembly produced in my /bin folder and, as a result of compilation, there will just be one other assembly placed in the ASP.NET temp folder. As for finding other component assemblies in these folders, that may be true, but those assemblies are not for the ASP.NET project's code itself, they are for the references. > You'll also find an assembly for each component > in the "assembly" sundirectory of your app. [quoted text clipped - 158 lines] >>>>>>>> process only. >>>>>>>> Thanks re: !> When I look in the ASP.NET Temporary Files directory for 1.1 apps., I see just one assembly Evidently, your .Net Framework 1.1 works diffently than mine. I'll have to go back and revise the ASP.NET books I've written if that's the case. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> Yes, but he said that this assembly was created one per page, and they aren't. [quoted text clipped - 147 lines] >>>>>>>>> compiling does not produce further assemblies as it is an in-memory process only. >>>>>>>>> Thanks I guess so. I have lots of books that have incorrect information in them. > re: > !> When I look in the ASP.NET Temporary Files directory for 1.1 apps., I [quoted text clipped - 192 lines] >>>>>>>>>> in-memory process only. >>>>>>>>>> Thanks re: !>I guess so. I have lots of books that have incorrect information in them. It's just that there were 6 authors, 10 technical reviewers, an editorial review board and a technical lead for the last book...on the most acclaimed ASP.NET book publisher of all : Wrox. That something that basic would have escaped all of us, doesn't make sense. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >I guess so. I have lots of books that have incorrect information in them. > [quoted text clipped - 164 lines] >>>>>>>>>>> compiling does not produce further assemblies as it is an in-memory process only. >>>>>>>>>>> Thanks I can't change the experience I've had with VS 2003 and the 1.1 Framework Juan. I have always found that the assemblies are generated just as I have described. How hard you worked on your book doesn't change that. > re: > !>I guess so. I have lots of books that have incorrect information in [quoted text clipped - 210 lines] >>>>>>>>>>>> in-memory process only. >>>>>>>>>>>> Thanks re: !> I have always found that the assemblies are generated just as I have described. Right. I can say the same thing. :-) All that needs to be accounted for is why I wind up with an assembly per page in the ASP.NET temp files directory...while you don't. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >I can't change the experience I've had with VS 2003 and the 1.1 Framework Juan. > [quoted text clipped - 185 lines] >>>>>>>>>>>>> compiling does not produce further assemblies as it is an in-memory process only. >>>>>>>>>>>>> Thanks > All that needs to be accounted for is why I wind up with an assembly > per page in the ASP.NET temp files directory...while you don't. FWIW, I've been watching this thread with interest, and still can't find any way to create a web application (with no additional referenced assemblies) containing more than one aspx page which produces anything other than one DLL... There must be some setting somewhere... There's no other way I can think of where several very experienced people whose opinion I respect can disagree totally on something which, as you rightly point out, is about as fundamental as it gets... SignatureMark Rae ASP.NET MVP http://www.markrae.net re: !> There's no other way I can think of where several very experienced people !> whose opinion I respect can disagree totally on something Well, we're not actually disagreeing. We're just reporting different experiences. :-) re: !> is about as fundamental as it gets... It sure is. re: !> There must be some setting somewhere... I don't recall setting anything which would change the compilation model. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> All that needs to be accounted for is why I wind up with an assembly >> per page in the ASP.NET temp files directory...while you don't. [quoted text clipped - 6 lines] > There's no other way I can think of where several very experienced people whose opinion I respect can disagree totally > on something which, as you rightly point out, is about as fundamental as it gets... > re: > !> He has also said in this thread that VS 2003 produced > !> multiple assemblies (one for each page). > He was talking about a different kind of assembly: JIT-compiled > assemblies. Those go in the Temporary ASP.NET Files directory. I still say these are not Jit Compiled. These are shadow copies. and there is still only 1 per project not 1 per page. If someone wants to find an official reference that contradicts this then go for it, but I really don't think you'll find one. -- Rory re: !> there is still only 1 per project not 1 per page I suggest you examine your ASP.NET Temporary Files directory for any ASP.NET 1.1 application you have running. You'll find one assembly for every page, not one assembly per project, and they *are* JIT-compled. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> He has also said in this thread that VS 2003 produced >> !> multiple assemblies (one for each page). >> He was talking about a different kind of assembly: JIT-compiled >> assemblies. Those go in the Temporary ASP.NET Files directory. > I still say these are not Jit Compiled. These are shadow copies. and there is still only 1 per project not 1 per page. > If someone wants to find an official reference that contradicts this then go for it, but I really don't think you'll > find one. > Rory > re: > !> there is still only 1 per project not 1 per page > > I suggest you examine your ASP.NET Temporary Files > directory for any ASP.NET 1.1 application you have running. I have Juan and, as expected and experienced for 5 years now, just one assembly for the project exists in the /bin folder of the project and the JIT version is in the temp folder. > You'll find one assembly for every page, not one assembly per project, and > they *are* JIT-compled. [quoted text clipped - 17 lines] > >> Rory >> re: >> !> He has also said in this thread that VS 2003 produced [quoted text clipped - 4 lines] > I still say these are not Jit Compiled. These are shadow copies. and there > is still only 1 per project not 1 per page. That's where we disagree Rory. The assembly in the temp folder *is* the JIT version of the project assembly. http://www.codeproject.com/aspnet/PreCompileAspx.asp I also found this (look at the temporary files section) http://msdn2.microsoft.com/en-us/library/aa479328.aspx#aspnet_http_runtime_topic5 > If someone wants to find an official reference that contradicts this then > go for it, but I really don't think you'll find one. > > -- > Rory >>> !> He has also said in this thread that VS 2003 produced >>> !> multiple assemblies (one for each page). [quoted text clipped - 10 lines] > http://msdn2.microsoft.com/en-us/library/aa479328.aspx#aspnet_http_run > time_topic5 Thanks Scott Interestingly this 2nd article seems to suggest that Bruce is correct under certain circumstances ...... --------------------------------------------- By design, the HttpApplication object looks for a class named after the requested ASPX file. If the page is named sample.aspx, then the corresponding class to load is named ASP.sample_aspx. The application object looks for such a class in all of the assembly folders of the Web application—the Global Assembly Cache (GAC), the Bin subfolder, and the Temporary ASP.NET Files folder. If no such class is found, the HTTP infrastructure parses the source code of the .aspx file, creates a C# or Visual Basic .NET class (depending on the language set on the .aspx page), and compiles it on the fly. The newly created assembly has a randomly generated name and is located in an application-specific subfolder of the following path: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files. --------------------------------------------- I have yet to try this but it seems to apply when the ASPX represents a class which is not in the project assembly. I have no idea what would cause that though. Interesting...... -- Rory Yes, this would be in scenarios where you just deploy your pages (.aspx), but no assembly. This is what folks who don't use the code-behind model would experience. But, I was clear in my earlier posts that this is *not* the scenario I was referring to. >>>> !> He has also said in this thread that VS 2003 produced >>>> !> multiple assemblies (one for each page). [quoted text clipped - 37 lines] > -- > Rory > Yes, this would be in scenarios where you just deploy your pages > (.aspx), but no assembly. This is what folks who don't use the > code-behind model would experience. But, I was clear in my earlier > posts that this is *not* the scenario I was referring to. Thanks very much Scott, this clears things up nicely (in my head at least). I think I had missed somehow the first couple of posts between yourself and Juan. I at least have learned something here so thanks for that ( to you and everybody else) I hope everyone else finds what they're looking for :) re: !> this clears things up nicely It doesn't for me. :-( See my just sent-in reply, where I state that the app uses both inline and codebehind pages. I *still* wind up with an assembly for each page, in the ASP.NET temp files dir, even though the app uses the single-assembly per project model. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> Yes, this would be in scenarios where you just deploy your pages >> (.aspx), but no assembly. This is what folks who don't use the [quoted text clipped - 8 lines] > > I hope everyone else finds what they're looking for :) > re: > !> this clears things up nicely [quoted text clipped - 7 lines] > files dir, > even though the app uses the single-assembly per project model. What happens if you build an app. using all code-behind pages and no inline pages AND you deploy the single IL assembly in the project/bin folder? re: !> What happens if you build an app. using all code-behind pages and no inline !> pages AND you deploy the single IL assembly in the project/bin folder? I don't know because I seldom use codebehind. I had to be dragged into using codebehind in the admin pages for the app while using inline code for most of the pages. I think that using codebehind is a waste of time, given that the code in codebehind files has to be compiled twice before it can be used. AFAIK, there's nothing which can be done in codebehind which can't be done inline, so why add unnecessary complexity to apps ? Btw, we have really gone very far OT for this thread. But, I suppose that's normal for programmers... :-) The thread originally concerned ASP.NET 2.0, and we've been discussing ASP.NET 1.1 for quite a while. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> this clears things up nicely [quoted text clipped - 9 lines] > What happens if you build an app. using all code-behind pages and no inline pages AND you deploy the single IL > assembly in the project/bin folder? > !> What happens if you build an app. using all code-behind pages and > no inline > !> pages AND you deploy the single IL assembly in the project/bin > folder? > I don't know because I seldom use codebehind. I think we have our answer here. > AFAIK, there's nothing which can be done in codebehind which can't be > done inline, so why add unnecessary complexity to apps ? At runtime sure. but at design time I find that it helps to seperate the markup and the code. Also we distribute our code and it was suggested (before the whole ease of decompilation of IL was discovered) that we didn't want to give our source code away as it would have been is laid bare in the Aspx files. Also how is code sharable between pages when there is no code behind? Are you seriously telling me that all your pages are that different? -- Rory > Also we distribute our code I should have said we distribute our binaries -- Rory re: !> Also how is code sharable between pages when there is no code behind? I compile classes into assemblies. I can call their methods/properties from any page. It seems much more efficient, to me, to do it that way. I can reuse the assemblies in other apps, too. re: > Are you seriously telling me that all your pages are that different? See above. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> !> What happens if you build an app. using all code-behind pages and >> no inline [quoted text clipped - 18 lines] > -- > Rory Inline.... > re: > !> What happens if you build an app. using all code-behind pages and no > inline > !> pages AND you deploy the single IL assembly in the project/bin folder? > > I don't know because I seldom use codebehind. Well, I think this is the heart of the issue. Let's just use some rudimentary detective skills here. You rarely use code-behind (the VS .NET 2003 default) and get multiple assemblies. I never use them and always get single assemblies. As I've said a couple of times, I believe that when you use the inline model, you will get an assembly per page, but when you use code-behind you will get just one assembly for all the page classes. Here is an article I found that supports this (the code-behind model anyway): http://aspnetresources.com/articles/debug_code_in_production.aspx In particular, this paragraph is of interest (and supports my position): "The sample project, TestDebug, has two pages named test1.aspx and test2.aspx. Note that every page is actually a class. The project itself compiles executable code into a dll, TestDebug.dll. Quite naturally, we expect to see both test1 and test2 classes inside this DLL." This excerpt is discussing the temporary assembly, not the project/bin assembly, just in case you missed it. > I had to be dragged into using codebehind in the admin pages > for the app while using inline code for most of the pages. I think that because you have a mixed model, you are seeing the multiple assemblies. As you state, you don't know what would happen when a 100% code-behind model is followed. > I think that using codebehind is a waste of time, given that the code > in codebehind files has to be compiled twice before it can be used. Fair enough, but I find the inline model just perpetuates the "spagehetti code" of classic ASP and does us no good when wanting to separate the UI from the buisness logic of our applications. In addition, it makes team development more tricky. I'll never go back to an inline model if I can help it. > AFAIK, there's nothing which can be done in codebehind which > can't be done inline, so why add unnecessary complexity to apps ? How do you separate your programming logic from your presentation logic in the inline model (saying that it's separated by the <SCRIPT> block at the top of the page isn't going to be a sufficient answer to someone seeking true nTier architecture). Does it add more complexity, I guess. But, there are millions who find the separation of presentation markup vs. programming code a benefit well worth the extra file. > Btw, we have really gone very far OT for this thread. > But, I suppose that's normal for programmers... :-) Yes, but if we can clear this up, it's time (and keystrokes) well spent. Not to mention, I don't think we've detracted from the OP as it seems to have been answered (it was my OP after all!). > The thread originally concerned ASP.NET 2.0, > and we've been discussing ASP.NET 1.1 for quite a while. [quoted text clipped - 19 lines] >> inline pages AND you deploy the single IL assembly in the project/bin >> folder? re: !> Well, I think this is the heart of the issue. Let's just use some !> rudimentary detective skills here. You rarely use code-behind (the VS .NET !> 2003 default) and get multiple assemblies. I never use them and always get !> single assemblies. Did you miss the explanation in which I said that my app uses *both* codebehind (for the admin pages) and inline code ( for most of the app ) ? re: !> As I've said a couple of times, I believe that when you !> use the inline model, you will get an assembly per page, but when you use !> code-behind you will get just one assembly for all the page classes. Surely, you can't draw the conclusion that you are trying to draw from a mixed model. If I were, in fact, only using inline code, you might have an argument but, since I I'm not, you are grasping at straws trying to justify your postulates. re: !> I think that because you have a mixed model, you are seeing the multiple assemblies. Are you saying that because there's some pages which use codebehind, that the compiler will use the single-page-per-assembly mode for all pages ? That doesn't sound correct to me. What I would expect, in that scenarion, is that all codebehind pages would be compiled into a single assembly and the rest would be compiled as single-assembly-per-page. re: !> How do you separate your programming logic from your presentation logic in the inline model I don't find it necessary to do that. I understand that some programmers prefer that model, though. What I do is compile classes into assemblies whose properties/methods I can call from any page. That's enough separation for me. re: !> Yes, but if we can clear this up, it's time (and keystrokes) well spent. I'll agree on that. From my end all I can do is bump this up the programming food chain. Maybe somebody in the ASP.NET Dev Team can shed light on this. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== > Inline.... > [quoted text clipped - 68 lines] >>> What happens if you build an app. using all code-behind pages and no inline pages AND you deploy the single IL >>> assembly in the project/bin folder? > re: > !> Well, I think this is the heart of the issue. Let's just use some [quoted text clipped - 6 lines] > Did you miss the explanation in which I said that my app uses *both* > codebehind (for the admin pages) and inline code ( for most of the app ) ? Not at all, but I believe that because you are using both, you aren't getting the same effect as if you just were using straight code-behind. > re: > !> As I've said a couple of times, I believe that when you [quoted text clipped - 4 lines] > Surely, you can't draw the conclusion that you are trying to draw from a > mixed model. All I know is that you are the one saying that you get multiple assemblies and you are also the one that hasn't used the straight code-behind model. It seems reasonable to me that because your only examples use the inline model that the inline model is the culprit. > If I were, in fact, only using inline code, you might have an argument > but, > since I I'm not, you are grasping at straws trying to justify your > postulates. I'm not grasping at straws, I'm using simple reasoning. I've said that inline will cause multiple assemblies. We all seem to be in agreement on that. I've also said that straight code-behind will cause one assembly. I've tried it (for about 5 years now) and you haven't and seem unwilling to do so (why, I don't know). Who's grasping? The evidence you provide for getting multiple assemblies seems to always have inline pages involved in the mix. The evidence I provide for a single assembly never involves inline pages - it seems reasonable to assume that the use of the inline page model is the key here. I don't think there is anything biased or far-fetched about coming to that conclusion. > re: > !> I think that because you have a mixed model, you are seeing the [quoted text clipped - 3 lines] > that the compiler will use the single-page-per-assembly mode for all pages > ? Perhaps, I don't know for sure, but it is not outside the realm of possibility or even that far-fetched. It may be that the process is more easily accomplished when only one assembly generation scheme is used, rather than two and since inline pages *must* use the one assembly per page model, that is the one that gets used (just a guess - in for a penny...in for a pound, as they say). > That doesn't sound correct to me. > > What I would expect, in that scenarion, is that all codebehind pages > would be compiled into a single assembly and the rest would be > compiled as single-assembly-per-page. See above comments (process assemblies via 2 rules vs. one). > re: > !> How do you separate your programming logic from your presentation logic [quoted text clipped - 6 lines] > can call from any page. > That's enough separation for me. Again, fair enough (and that's why the inline model exists today). But, you can't deny that nTier and MVC architectures are quite prevelant in Enterprise development. > re: > !> Yes, but if we can clear this up, it's time (and keystrokes) well [quoted text clipped - 4 lines] > From my end all I can do is bump this up the programming food chain. > Maybe somebody in the ASP.NET Dev Team can shed light on this. I would suggest (just for kicks) that you create a new ASP.NET 1.1 Project in VS .NET 2003 (if you still have it installed) and just add a couple of pages (no code is needed in those pages). Make sure that all the pages use the code-behind model and check it out. Since I can attest to the two behaviors based on the two different ways of creating the pages, but you've not used the 100% code-behind scenario, you could see for yourself what I've been describing. This would also confirm for you that what that article I referenced is referring to is not an anomoly, it is the default architecture for ASP .NET 1.1 sites built with VS .NET 2003 > Juan T. Llibre, asp.net MVP > asp.net faq : http://asp.net.do/faq/ [quoted text clipped - 88 lines] >>>> inline pages AND you deploy the single IL assembly in the project/bin >>>> folder? re: !> I've said that inline will cause multiple assemblies. !> I've also said that straight code-behind will cause one assembly. We'll see. I'm setting up a VS 2003 test app which only uses codebehind. Two pages should suffice. If only one assembly is created, fine. If two assemblies are created, your theory siinks. re: !> seem unwilling to do so Why would you ascribe that thinking to me ? Just as I read what you wrote, I was geting ready to test the model. Please, have some respect for me. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> Well, I think this is the heart of the issue. Let's just use some [quoted text clipped - 153 lines] >>>>> What happens if you build an app. using all code-behind pages and no inline pages AND you deploy the single IL >>>>> assembly in the project/bin folder? re: !> I would suggest (just for kicks) that you create a new ASP.NET 1.1 Project !> in VS .NET 2003 (if you still have it installed) and just add a couple of !> pages (no code is needed in those pages). Make sure that all the pages use !> the code-behind model and check it out. I have finished the test, using only codebehind for two pages. As predicted, I wound up with an assembly for each of the 2 pages. I also have a project assembly and a global.asax assembly. That's a total of 4 DLLs for a simple project with 2 pages. To me, that's ample proof that your statement that : "I've also said that straight code-behind will cause one assembly" is not correct under all circumstances. If you want to, I'll zip up the files so you can test or, if you prefer, you can repro as I did...and write a simple app with two pages. Juan T. Llibre, asp.net MVP asp.net faq : http://asp.net.do/faq/ foros de asp.net, en español : http://asp.net.do/foros/ ====================================== >> re: >> !> Well, I think this is the heart of the issue. Let's just use some [quoted text clipped - 69 lines] >> From my end all I can do is bump this up the programming food chain. >> Maybe somebody in the ASP.NET Dev Team can shed light on this. > I would suggest (just for kicks) that you create a new ASP.NET 1.1 Project in VS .NET 2003 (if you still have it > installed) and just add a couple of pages (no code is needed in those pages). Make sure that all the pages use the [quoted text clipped - 79 lines] >>>>> What happens if you build an app. using all code-behind pages and no inline pages AND you deploy the single IL >>>>> assembly in the project/bin folder? > re: > !> I would suggest (just for kicks) that you create a new ASP.NET 1.1 [quoted text clipped - 17 lines] > prefer, you can repro as I did...and write a simple app with two > pages. If I could get a zip of what you did, I would love to have a look and see how it compares to what I would have expected. Mail to RoryBecker [A T ] [Gee]Mail [Dot]Com Thanks very much in advance -- Rory Bruce, I'm sorry but you are just plain wrong on ASP .NET Web Applications (both 1.1 and 2.0). Regardless of how many pages you have, you will wind up with just one physical assembly file per application. Yes, there is the initial one (placed in the /bin folder) and then a compiled version of it placed in the Temporary ASP.NET folder that IIS actually uses, but just one per application. -Scott >1 dll per page: > [quoted text clipped - 85 lines] >> >> Not really, though Web Deployment Projects add some extra options... Hi Bruce, Thanks for the explanations. I have a couple of comments questions, inline.... > question 2: > > .net 2.0 (just like 1.0) creates temp folders that the web site is copied > to and compiled. where these folders are depends on configuration but the > default is under the .net installation folder. Yes, but in 1.1 the initial IL assembly was placed in the /bin folder of the ASP .NET project directory. ASP .NET Web Sites don't seem to have this? That is what I was inquiring about. > also just like 1.1 a assembly is created per page (for both web sites and > web applications), so finding the folder for the desired page is a little > work. ??? In 1.1 there was not one assembly per page. There was one assembly per project. You could have 1000 pages and just one assembly. > you can precompile the site to a work folder with the aspnet_compiler, and > its easier to find stuff, because all assemblies are in the bin folder. Is that NGen or someting else that pre-comiles it? Thanks Bruce! I hope all of you got this right by now before samueltilden@gmail.com comes back in. keep on going if you have some more true facts to add and 100% sure of your answers. Thanks by the way. > I've asked this before, but not gotten any clear answers, so I'd figure > I'd try again. [quoted text clipped - 30 lines] > > Scott >I hope all of you got this right by now before samueltilden@gmail.com comes >back in. > > keep on going if you have some more true facts to add and 100% sure of > your answers. ????? Smile; Just kidding.... Thanks for all the good info >>I hope all of you got this right by now before samueltilden@gmail.com >>comes back in. [quoted text clipped - 3 lines] > > ????? I would if I understood any of what you saying. > Smile; Just kidding.... > [quoted text clipped - 7 lines] >> >> ?????
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.