|
 | |
 | bitmask | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 8/30/2005 3:51:36 PM |
| 0/0 |   |
|
In the new compilation model the code-behind compiles at the same time the runtime parses the ASPX file and compiles it. The resulting assembly will end up in a sub directory of the Temporary ASP.NET Files folder where the framework is installed (unless you use the precompilation tool, see http://odetocode.com/Articles/417.aspx). |
| mhardy | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 8/31/2005 8:28:45 PM |
| 0/0 | |
|
As bitmask points out in the default code-behind model code files are compiled at runtime and DLLs are created in a temp directory of the framework. This of course means you need to deploy all code files with the application if you use this model. Two other models are available in 2.0 but neither will provide what you are looking for. They are available via Build / Publish Web Site. One method will precompile your entire site into DLLs and aspx stubs that contain no code nor markup. Using this method you must compile and deploy the entire site - which means it must be deleted, yes, deleted first. If you have a site with hundreds of files and you need to make a change to only one of them - from what I understand you need to delete your entire web site and re-deploy everything. The other method will allow the site to be 'updatable'. This method will create aspx files that contain markup as well as a number of DLLS. Each of these methods compiles all of the necessary files to a sepearte directory and though the updatable method still maintains your markup in the aspx files, THEY ARE DIFFERENT. Your original aspx files can not be deployed; the modified version created during the 'Publish' must be deployed because slight changes are made to the Page directive to properly link the page to the compiled DLL. There is currently NO WAY to hit compile, and have all pages compiled to one or more DLLs into your bin directory leaving your aspx files untouched. IMHO this is an absolutely deplorable decision and I only hope this will be changed before release - but it appears unlikely. I can't begin to explain how frustrating the currently available deployment models are but here are a few links regarding this very issue (please vote on them): http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackId=d35e0b41-d07f-429d-9137-15d0eaaee58ehttp://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackId=09af3c3f-adc7-436d-ae8d-d7bcf174e0c7I draw these conclusions from working with the July CTP of Visual Studio 2005. If this is no longer the case in the August release, or I have completely overlooked the ability to compile directly to the \bin please let us all know. I would very much like to be wrong. Mike |
| mhardy | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 9/2/2005 1:54:21 AM |
| 0/0 | |
|
 bitmask wrote: |
The -fixednames switch on the precompiler will produce dependable assembly names. It is possible to patch just the code for one web form this way.
|
|
Fantastic! However, here's the rub, since they are all recreated during Publish they are all dated the same making change set deployment a painstaking, time consuming exercise. | bitmask wrote: |
Even still, I'm not sure why deploying from a different directory of ASPX files would be such a pain. All you need is a staging area, which the publish option or the aspnet_compiler can setup for you.
|
|
Very simply because it creates more work. Let me explain... I maintain around 30 sites each with between 10-200 pages. I frequently make changes to individual pages, or multiple pages within a single application of a site. Once these changes are made and tested locally (by simply hitting run), I want them deployed - just the pages that changed (and any relevant dlls). Especially if they're bug fixes, I want them deployed as fast as possible - but absolutely only those pages. Deploying the entire web site is not an option, for countless reasons. In essence, I want to deploy directly from the IDE, but only those files that have changed. i.e. make change(s), hit run, test changes, deploy changes. With the current model that is just not possible. If I 'Publish' to a staging area I then need to browse to the staging area, try to find the file(s) that changed (which all have the same date now), connect to my server and copy the files up manually. That is a considerable amount of overhead when done frequently throughout the day. I of course can't set the Publish options to publish to the live server because that would delete my entire site, I can't believe that's really an option for anyone. Unfortunately most of the small to medium size businesses I work with do not have a QA department nor a stringent deployment schedule. Though that would be nice, it is simply not the case for numerous companies. They want changes, they want them now, and they want minimal downtime (i.e. no deleting the entire site! :) So the ability to merge DLLs, though a nice option, is not really of great concern for me. I actually prefer the new method of having multiple DLLs so change is more contained. I guess it all boils down to the fact that my overall concern is that I still can not easily publish incremental changes. For so many websites that is absolutely key. The fact that I hit 'Publish' and receive a dialog that says "Existing files in the destination location will be deleted. Continue?" is almost laughable to me. But then again, maybe I'm just in the minority... ;) Thanks for the response Scott, I do much appreciate your insight. I'm just frustrated that what seems an obvious workflow is still not handled very well. I simply want, compile, test, deploy changes. Mike |
| RichardMathis | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/14/2005 7:58:47 AM |
| 0/0 | |
|
As I was reading through this thread, I was getting pretty excited because this is exactly the issue I'm encountering.
I work exactly like mhardy describes. Here is my real life issue that caused me to search the forums.
I dragged a comparevalidator onto a form that didn't need one as an experiment, and published the site that way. Now I need to remove that comparevalidator and reupload that page, here is what I've encountered.
Uploaded the filename.aspx, no go here (I knew it wouldn't), it asks for the .vb. I'd prefer not to upload the .vb, as I don't want to give sourcecode to customers without charging them for it.
I can't use the publish tool because it would delete the images would take a long time (meaning the site would be down for the duration), and the web.config is different on the live server (different smtp server, different connectionstrings, and I use a setting called istest which tells the site whether to use .local or .com for dynamically generated urls).
So I assume I need to upload the assemblies.
I see the msbuild options, and I know how to use the msbuild command prompt, but I'm trying really hard not to use it in this instance, as I have over 30 websites and I am trying to figure out how to use VS2005 to do what I want so when I need to do a quick change like this I can do so with minimal fuss.
At this point, with the full version of VS2005, can someone tell me what my most efficient means is for quickly editing one page out of dozens of websites and upload the appropriate assembly? Preferably without scrounging through my temp folders and trying to guess which assembly equates to the file's folder I just changed.
Here is my dream of how it would work (it would be even better than 1.1's ease of updating!)
A) Customer calls me and /members/featuredproperties.aspx has a typo.
B) I change the typo, click Build from the Build menu in VS2005.
C) I click copy website, open the ftp, browse to the precompiled_code folder.
D) I find App_Web_member_72uulx1k.dll and upload it.
Done.
Is that, or something like it possible at all? If so, I would appreciate someone who could steer me in the right direction. Working in asp.net 2.0 started as a dream, but the nightmare of constant constant updates for projects in progress is beginning to really increase my stress level.
Richard Mathis Dndorks Webmaster http://dndorks.com/TopWebcomics Webmaster http://topwebcomics.com/ |
| ScottGu | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/14/2005 4:16:50 PM |
| 0/0 | |
|
Hi Richard, Here is the web deployment project utility I mentioned earlier in the thread: http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspxHere is information on how to download it and ask questions: http://weblogs.asp.net/scottgu/archive/2005/11/10/430283.aspx
This will allow you to build your website and have more control over assembly versioning (for example: MyCompany.MyWebApp). For example, you could have a single assembly with a fixed name if you want -- in which case you would just copy the .aspx file and the 1 .dll assembly for the scenario you listed above (just like VS 2003). You could also alternatively have a separate assembly per folder if you wanted to make more granular updates. Hope this helps, Scott |
| RichardMathis | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/15/2005 12:00:46 AM |
| 0/0 | |
|
I just wanted to say thanks! This has so far worked tremendously, and even one upped my previous 1.1 interface because now I'm not so afraid I might "accidentally" upload the web.config when I upload everything else. I will say that I, like many I think, work off of a development server and encountered the problem described in KB 843584, I followed the steps, and now I'm up and running. Fantastic tool Scott!
Richard Mathis Dndorks Webmaster http://dndorks.com/TopWebcomics Webmaster http://topwebcomics.com/ |
| SimonCal | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/15/2005 11:21:33 PM |
| 0/0 | |
|
The different aspects of compilation and merge using the tools aspnet_merge and aspnet_compiler is something that we are working on a whitepaper for and will be linked off the Web Deployment Projects download page. We are hoping to cover aspects of the release management processes too. For example the consideration to keep say, a single assembly per file (aspnet_compiler -fixednames) v aspnet_compiler and aspnet_merge for folder level assemblies.
Very briefly, with the current compilation and merge tools therefore, you effectively have a range of possibilities for given scenarios which have effects on forms of release management.
1. Regular, dynamic compilation where the production server has all sources and performs all compilations;
2. Aspnet_compiler: pre-compile 'in-place' against the production web site (that consists of all it's sources): This removes the hit for compilation as stated in #1;
3. Aspnet_compiler: pre-compile, updatable with fixednames or not: Still performs page compilation in productiuon, but allows quick edits to productions. Removes source code form production. With fixednames assemblies are created per 'page';
4. Aspnet_compiler: pre-compile, no-updates with fixednames or not. Like #3, no source is in production, no markup exists either.
Add in aspnet_merge:
5. Running on pre-compiled sites (#3, #4 the fixednames option to the aspnet_compiler is irrelevant),: The assemblies can be (prefix) named and merged per folder;
6. Like #5, you can also merge to the entire web ui content and name that assembly. Only web content is merged, folder stuff like App_Code assemblies are left untouched;
7. Like #5 you can also merge the entire site and name that assembly.
Under merge, you still retain the .compiled or dummy markup files depending on the pre-compialtion choice prior to merge.
Finally, the runtime still supports the old codebehind model, where an assembly is prebuilt and placed in Bin, and the page has the codebehind reference. VS however, does not support the model.
Simon
This posting is provided "AS IS" with no warranties, and confers no rights. |
| omar_k | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/18/2005 11:03:18 PM |
| 0/0 | |
|
You may be mis-understanding the statement made by Simon. Its true the Visual Studio 2005 tool does not support the Visual Studio 2003 code behind model.
However we have a new code-behind model in Visual Studio 2005 that provides the same benefits of the model in VS2003 - such as your code being in a seperate file from the ASPX page. However the VS 2005 model has some additional enhancements such as the generated code being put in a partial class so its not always needing to be synced up by the design view which was very buggy and error prone in VS2003.
We also provide a migration tool that upgrades the VS2003 code-behind syntax to the VS2005 syntax.
I just wanted to clarify that we do have a code-behind model in VS2005, its just implemented a bit differently than how it was in VS2003.
--Omar
Omar Khan Visual Studio Web Tools |
| ryedin3 | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/21/2005 2:51:38 PM |
| 0/0 | |
|
I understood Simon's statement. He said the old VS2003 code behind model which was so natural for everyone, where you have the dlls in the bin folder and everything has access to your classes and types inherently (even user controls without having to write abstract stub classes), is still supported by the runtime but not by the IDE. That's just peachy.
The "enhancement" of partial classes to store the auto-generated code snippets is not so much an enhancement as a nuisance. For one, where can I find this other partial class file and change it? If I do change it, does it just get changed back the next time I open the designer? I want total control over everything that goes into my project. VS 2005 takes a lot of this control away. This model might be useful for newbies. It might be useful for some people who want to use it. But it really sucks for those of us who built our entire architecture around the old model, especially since it's being crammed down our throats. Why wouldn't you just support both models out of the box? It seems you were just rushed to get a product out the door so you said "screw it, they'll just have to deal with this". Project-less websites were not a good idea. Sorry, that's just the way it is.
That whole "Web Deployment Projects" thing seems like such an afterthought. It's a workaround. I hate workarounds. Not only that, it doesn't really solve the problem. Yes it merges assemblies which makes deployment slightly easier, but that does me no good during development and debugging and it's a lot of bunk setup time that brings us full circle to where we were a year ago with VS.NET 2003 (as far as deployment goes). I still have to write stub classes in the APP_CODE directory for any user controls I want to use dynamically in my application. That is extremely clumsy. Did anyone who thought up that model really think it was great? Did they sit down and say "you know, it would make for really easy development if we have all web files in separate assemblies and create a bunch of abstract classes and put them in a different special folder for anything you want to re-use throughout your project"
Generics are awesome, so are a lot of the library additions made for 2.0. But the changes made to the web side of things and the IDE are very questionable. It feels more like FrontPage 2005 than VS 2005. Give me back my project-bound web development (integrated into the IDE, not as a clumsy workaround), and I'll be happy.
|
| omar_k | | Asp.Net User |
| Re: Developing the Old Way Using Codebehind and a Compiled Application | 11/22/2005 1:42:50 AM |
| 0/0 | |
|
Hi ryedin3, I wanted to respond and help explain some of the motivations behind the changes you are talking about. There is a great blog post by Scott Guthrie that details many of benefits of the changes we have made to the web project system. It can be found at: http://weblogs.asp.net/scottgu/archive/2005/08/21/423201.aspx. If you look at that post, it should hopefully shed some light on the benefits of the changes we have made. Our primary goal was to make day-to-day iterative development tasks more flexible, quicker, and better suited for team development where multiple individuals might be working on the same web application but on different sets of pages. In combination with this more flexible development-time model, we are delivering web deployment projects to handle the build / deploy to staging / production aspects which generally is a seperate process from the day-to-day development activity. I fully agree that our changes mean some scenarios like creating shared user controls that can be dynamically loaded from code are not as optimized as before, however we felt the overall benefits of the changes outwieghed some of these downsides. For loading user controls, if you are only loading them dynamically from pages, you should be able to just add a <@register> directive to a shared user control which should allow you to dynamically load it from your code in your page. This should avoid having to create abstract base classes. However if you are loading the user control from other shared code such as a stand-alone class in the App_Code, then yes you will need an abstract base for it. For the partial classes question. The primary problem before was that control declarations were persisted twice once in the ASPX page and once in the code-behind file in the generated code. VS 2003 has many issues around keeping these two declaractions in sync. For instance, if you typed in <asp:button id=button1> in the ASPX page, then you would have to manually declare that control in the InitializeComponent method, or you would have to switch to design view and back. If you want to customize any of the code being run at startup, you can always declare your own controls or add your own property settings or event binding in the OnInit method of the web page. Are there particular scenarios that you cannot achieve with generated declarations being hidden in a partial class? I hope this helps clarify a bit where the changes you mention are coming from. I completely understand and agree that the model is different now, and some things may require a bit of re-learning to figure out. Please continue to let us know which specific things you are finding difficult so we can try to help in whatever ways possible. Thanks.
Omar Khan Visual Studio Web Tools |
|
| |
Free Download:
Books:  ASP.NET in a Nutshell: A Desktop Quick Reference Authors: G. Andrew Duthie, Matthew MacDonald, Pages: 979, Published: 2003 Microsoft ASP.NET Programming with Microsoft Visual C# .NET Step by Step: Version 2003 Authors: G. Andrew Duthie, Pages: 601, Published: 2003 Microsoft ASP.NET Programming with Microsoft Visual Basic .NET Step by Step: Version 2003 Authors: G. Andrew Duthie, Pages: 624, Published: 2003 Professional Web Parts and Custom Controls with ASP.NET 2.0 Authors: Peter Vogel, Pages: 449, Published: 2005 MCAD/MCSD.NET: Developing and Implementing Web Applications with Visual Basic.NET and Visual Studio.NET Authors: Mike Gunderloy, Pages: 1104, Published: 2003 ASP.net Web Developer's Guide: Web Developer's Guide Authors: Robert Patton, Mesbah Ahmed, Jonothon Ortiz, Wei Meng Lee, Pages: 736, Published: 2002 ASP.NET: tips, tutorials, and code Authors: Scott Mitchell, Doug Seven, Stephen Walther, Donny Mack, Billy Anders, Adam Nathan, Dan Wahlin, Pages: 878, Published: 2002 Developing and Implementing Web Applications with Visual C# .NET and Visual Studio .NET: Exam Cram 2, McAd Exam 70-315 Authors: Kirk Hausman, Amit Kalani, Priti Kalani, Ed Tittel, Pages: 555, Published: 2003 Pro Visual C++/CLI and the . NET 3. 5 Platform Authors: Stephen R. G. Fraser, Pages: 1048, Published: 2008 Web:Developing the Old Way Using Codebehind and a Compiled Application ... Developing the Old Way Using Codebehind and a Compiled Application. Last post 03 -08-2006 5:25 PM by mhardy. 23 replies. Sort Posts: ... Developing the Old Way Using Codebehind and a Compiled Application ... Is it possbile to develop using the 1.x compiler model with a codebehind that is compiled into the DLL in the /bin directory? ... ASP 101 - Using ASP.NET Code-Behind Without Visual Studio.NET i understand that there is a way to run a code-behind page inheriting from a ... be proven wrong... here's how you can implement code-behind using just a plain old .... Since we're not using VS.NET, it wasn't compiled and the application can't .... Internet.com eBook: Developing a Content Management System Strategy ... The great ASP.NET code-behind debate Mar 7, 2003 ... NET is the way that it has taken the Windows software design and ... Although there are several references that insist codebehind is the right way to develop ASP. ... It’s possible to compile applications with errors in the inline ... Having given the two main arguments for using code-behind files, ... How to work with code-behind class files in an ASP.NET application ... This article demonstrates how to develop .aspx pages that use code-behind class files in Microsoft ASP. ... NET Web application by using Microsoft Visual Basic .NET ... If your code-behind class files will be compiled on demand instead of ... is spelled and capitalized the same way as the code-behind class name. ... Cairo Cafe ( Tech Talks ): ASP.NET 2.0 Compilation In A Nutshell NET 1.x, if you are working using code behind model, after you compile your site ... After you finish developing your application you'll likely need to ... The old way of compilation that was known as Pre-Runtime compilation is still ... Dynamic Compilation in a Web Application - C# and stuff Nov 26, 2008 ... Hence the normal way to use a Web Site is simply to copy the ... You can choose to compiled the codebehind or the codebehind and ... it can a pain when e.g. developing User Controls. ... I tried using two User Controls on the same page, the one using CodeBehind and the other using CodeFile , and it ... CodeProject: Inline (Single File) vs. CodeBehind. Free source code ... All project class files (without the .aspx file itself) are compiled ..... It seems like everyone has accepted codebehind as the standard way of writing ASP. Net applications. I can understand the pros vs. cons of using codebehind, ... I would definitely like to hear from others that have tried developing in ASP. ... Developing ASP.Net 2.0 Code Behind pages for SharePoint: Using ... Make sure that it is compiled before accessing the page. .... Dave, No it is not possible to edit code behind files using SPD, only Visual Studio. ... roadburn’s sharepoint 2007 blog » Blog Archive » Custom Application Page MOSS .... I used this way. but I got error: An error occurred during the processing of . ... .NET Questions - ASP.NET In Line versus Code Behind use the web application model, where the code-behind / code-beside is compiled ... Surely the code-beside model is compiled at runtime, like inline code. ... You can certainly set it up that way (I do) but the page declaration needs to be ... Old documentation and old versions of VS defaulted to a declaration that ... |
|
Search This Site:
|
|