We've inherited an ASP.NET website. We've already converted it to a web application for different reasons.
But there are 2 folders with 2 .aspx pages inside that do some really kludgy things (creates a new aspx file with its corresponding code behind and save it inside one of those folders).
So when the project was a simple website, that worked because the created pages on runtime were compiled at request. This is not applicable to a web application.
We don't have time to re-code those ugly pages and do it as it should. So, is there a way to have those 2 pages (and the generated-at-runtime ones) excluded from the project and inside a website that is compiled at request? What other alternatives could you think of?
You can multiple Web Applications on a single site by designating them as separate applications within separate Virtual Directories in IIS. For this, just create a new Virtual Directory in IIS, right-click and go to Properties. Under the "Virtual Directory" tab, click Create. This will designate that Virtual Directory as a separate application.
The end result will be that "mysite.dom/VirtualDirectory1" and "mysite.dom/VirtualDirectory2" will be separate applications that can even run under a different ASP.NET runtime.
EDIT TO ADD that the downside of this is that the two applications are completely separate and cannot share Session or Application information. This can be easily solved via a Database or some other data store.
Related
I've been trying to understand the different types of compilation involved in ASP.NET and have come to seek some clarification regarding dynamic compilation of .aspx files. Specifically referencing the following statement from Microsoft's Understanding ASP.NET Dynamic Compilation:
"By default, ASP.NET Web pages and code files are compiled dynamically when users first request a resource, such as an ASP.NET page (.aspx file), from a Web site."
My question is simple, yet doesn't seem to be discussed anywhere.
Is it an HTTP GET or POST request that compile .aspx page? Or does it not matter?
and
If I can see requests (both GET and POST) to the .aspx page but there is no .dll or .compiled file created, is there a problem? The content of the .aspx file is correct.
Any help in understanding this aspect of ASP.NET compilation would be greatly appreciated. Thanks!
The compile is a one time event. And it depends on what kind of project you created.
if you create a asp.net web site, then pages are compiled on the fly - but ONLY the first time they are used - use by anyone. So you don't have to care or worry about this issue. But to answer your question? They are only compiled one time. Not each time.
If you create a asp.net web site application? Then when you deploy the site, all code and pages are compiled at deploy time. No runtime compile on the fly (that one time, first time) occurs. and I belive that you can deploy without a pre-compile for a web site application - and you notice quite a delay the first time the site is used as a result. But in this case - only one .dll for the site is created. This is really simular to a desktop application. You compile the project, and you get one .exe or one .dll. You may well see/find some addtional .dll's from libraries that you referenaced in the project also included in the bin folder.
As for the .dll? As noted, it depends on the type of site you created. If you created a asp.net web site application, then everything (most) is compiled into ONE .dll that resides in the bin folder. So each compiled page thus does not have a separate .dll.
The site is thus pre-compiled (or only compiled one time). For a asp.net web site (not a web site application), then you should/would in theory see a new .dll for each web page if you created a asp.net web site in place of a asp.net web site application. Some prefer a web site, since then you can update ONE page without a whole site re-compile.
But, if you have your own IIS server, then choosing a web site application is preferred. One big difference is that you can create custom logon and authentication providers with a web site app, but you can't with a web site. You can still have and create logons for that web site, but a web site application allows you to over ride and build your own authentication providers.
You as a general rule only want to create a asp.net web site application if you have your OWN IIS server. For most hosting plans (say low cost ones), then you have to use a asp.net web site - not a asp.net web site application - and in that case, then .dll's should appear for each web page in that case.
But as noted, in either case - once the page is compiled, it does not re-compile over and over each time such pages are used.
I m having a ASP.Net Webapplication it accessed by from many geography like India,China&America.In that application's login page fields are username,Password & Geography.
Based on this login page geography option the application's functionalities will change in all page.
In this project,If we add a feature for Indian users but that will not required for other geography users,So we use some conditions like if The geography is India means Enable the feature others means disable it.
problem here it is, in all pages we need to use so many conditions check,some time it creates conditions check overhead.
So we planing for divide the webappplication in to separate applications based on geography wise.
What I planing is,
In hosting environment
1.Keep the same project into Three(India,China,America) Subdirectories.
2.In root directory we have login page only .So once user select the geography means we need to redirect the corresponding subdirectory.
By this way we can maintain the changes which made based geography as separate.
But My doubt is...
If we keep the project as Three(India,China,America) Subdirectories means each directories are have same files ,bin and webconfig file,So I think we cant maintain more than one webconfig file in hosted ASP.Net application folder.
This Subdirectories idea is possible or not in IIS hosting environment?
Is any other options are available?
Experts please share your valuable ideas.
Thanks in Advance
Ramesh
Good afternoon Ramesh!
If I understand your question correctly you currently have 3 separate web roots and you want to use these as separate web applications that will be served to users based on geography in some way. You also want to maintain individual web configuration files for each as well. If this is your inquiry then this set-up is definitely possible within IIS 7 and above.
To provide this functionality this you can do the following:
Configure a single main site within the IIS. This site can point to a web root or nothing. If it points to a web root, whatever web.config that exists will be inherited by the web applications we will add in the next few steps. Otherwise, the machine.config will be used.
Add 3 separate web applications underneath this main site. Make sure to add the root path of each application to use the respective 3 paths for your web roots. The web applications will by default inherit web configurations from the main site as mentioned earlier, but you can include a separate web.config within each of these web root folders.
If you have seen my previous questions, you're aware that I'm in the process of updating some existing ASP pages, in an effort to move them from a Windows 2000 environment to a Windows server 2008 R2 environment. One of the pages offers the end-user the ability to upload a file to be processed later.
I re-wrote the original page that handled the uploading, using ASP.Net's file upload object. It works fine, but I'm running in to a snag when trying to integrate the new aspx pages in with the existing asp pages. The new aspx pages live in a subdirectory of the main application, along with a few other asp pages, but in order for the asp.net pages to function, I had to use the "convert to application" option on on the folder. When I did that, I think it broke the ability for the new aspx pages (and any other asp pages in the folder containing the aspx pages) to use the Session variables that the parent pages use.
I tried creating an application pool for the new folder's application, but that didn't make any difference. I also changed the managed pipeline from Integrated to Classic, both on the parent folder and on this folder with the aspx pages, but that also doesn't appear to have made any difference.
If anyone can shed some light on this, I'd be very grateful.
The main asp files live in folder named "dcn". There are several child folders in the "dcn" folder, many of which contain asp pages. Asp pages in those folders continue to work correctly. The folder which contains the aspx pages is called "CNAM", and it has now been converted to an application. Any asp page in this folder no longer seems to see the session variables that are available to the other folders/pages.
Thanks in advance for any insights or suggestions regarding this. Again, I really appreciate any assistance.
Mitchell
How to Share Session State Between Classic ASP and ASP.NET
Suppose I created a custom web application that consists of:
several assembly DLLs: web app, business logic, data services
multiple aspx pages and ascx custom controls that use them
custom configuration section
custom HTTP module
More or less the usual stuff.
I would like to deploy it to a particular sharepoint site under a certain subfolder. So if I access my sharepoint site via http://myserver:90/ (because I'm not using sites/some_site) I'd like my application to be available under http://myserver:90/webapp
I could manually add a virtual folder (not application because I would need to access some Sharepoint site's data) to my sharepoint site in IIS and manually edit site's web.config file to register my HTTP module and add my custom configuration section as well either putting my DLLs into GAC or put them in the _app_bin (so I don't have problems with CAS), but I don't think that's a good thing to do, because this web application may get deployed in an environment where this shouldn't/couldn't be possible.
So I figured I could build a WSP using Visual Studio 2010 and deploy it that way. But I don't have enough experience doing that.
I created a new sharepoint 2010 project. Is there a way I could add all non-executable application files (aspx, ascx) at once? I've seen the advanced tab of the WSP package where I can add my DLLs either to bin folder or GAC. I don't know whether I would also have to add any safe control and register certain classes?
So I suppose I need some pretty detailed and explanatory guidance here.
The only real way to do this would be to use the layouts folder to deploy your application via the wsp. This will let you depot any files that you would normally deploy with a.web application.
There are couple of problems however. The URL for your application will be http://SharePoint/somesite/_layouts/yourapp
This is a blessing and a curse. Your urls will be ugly but they will work under every SharePoint site. If your application depends on SharePoint context to function, that context will automatically be available based on the requesting URL.
To add a layouts folder under your share point project right click on the project and add a mapped folder to layouts. I would also recommend adding a sub folder under layouts for your application so that your application files don't conflict with the default files directly in the layouts folder.
For the http module, or any web.config modifications, you can use the spwebconfigmodification class.
Heres a walkthru: http://sharepointsolutions.blogspot.com/2006/12/using-spwebconfigmodificat_116736917110571614.html
We would like to have several internal web applications which use the same master page. Is there a way to store a master page in a common library referenced by all projects?
You can do this, but it is difficult and has quite a few drawbacks.
This process is similar to packaging up user controls as well. Basically you have a web application project that contains your master page. You can precompile this into a set of dlls using aspnet_compiler.
then you can use ilmerge.exe to put them all into a single dll that you then reference from your other projects.
You still need to have the markup in order for your pages to render properly in the designer, so you'll probably have to investigate VirtualPathProviders as well.
It's a kludgy solution and it has many drawbacks.
I've heard this works, I haven't tested it.
Create a separate project to house your master pages, since all master pages are like user controls and built into their own separate assembly. Run the build and try referencing the assembly of the master page.
Again, not tested, just something I've read before.
G'luck with it!
Given that these modules are part of the same web application, you should look at this approach:
Basically, you have one root web, which is set up as the(only) IIS web application.
You may plug in new web modules by creating ASP.NET Web Application projects and place under the root web, physically.
Set the build directory to root web's bin, eg. "..\bin". Don't create a IIS application/virtual directory.
Thereby, each web module compiles into its own DLL, which is itself a good thing.
When compiling, it is "merged" with the root web.
It is a great way for sharing master pages and user controls, and have different parts of the web site in different projects/assemblies.
Master pages and user controls will even work in design mode.
Hope this helps
Sharing master page across the application
Enjoy.. :)