Is it possible to share the App_Code directory and master pages with a nested application? I have a third-party newsletter application installed in my web app and I want it to share the same look and feel as the "parent" application. When I try, though, I get an error saying that the child application can't reference any of the exterior files.
I've done quite a bit of searching and found a lot of pages on overriding the Web.config in a child application, but I haven't been able to find anything that quite fits my situation.
The web server is running .NET 2.0 with IIS 5.0.
I have never tried this, but it might be possible to access the master page of the "outer" application by implementing a VirtualPathProvider in the nested application.
Related
I am about to convert my Winforms applications to an ASP.NET Web Application. The only question I have is the following:
My Winforms application connects to a server via TCP/IP connection (TCPClient), and handles all requests and commands through my own custom protocols (Strings sent that are validated server side and sent back to client)
Can I keep this same Server to handle the requests from my ASP.Net Web Application (I plan on using the same protocol)?
Will there be anything I have to change within the server? How different is migrating a Winforms application to an ASP.Net application?
Do you suggest I use WebForms or MVC?
Well, we might be confusing things here some what.
You have a asp.net application. Then the question is:
asp.net webforms application
or
asp.net webform web site
While both above are similar?
Well, in the first case, a web application means that you compile your code BEFORE web deploy, and for the most part this site is to be considered the WHOLE site (the web config file is in root etc.). And any external assemblies etc. are linked at compile (or publish time). And you are as a general rule NOT EDITING and design and working against the actual web site files. In other words, the folder that holds your project CAN NOT JUST be dragged say to a web server folder and it will work.
And of course this allows you to write custom handlers for pdf files or whatever.
So you can add + hook into the http handlers.
And of course this also allows you to build say a custom logon (authentication provider).
So, you can think of a web application more like a WHOLE application - just like say all the truckloads of source files that you have for a desktop application. You THEN compile this whole big thing, and you compile down to that .exe (or .dll).
You THEN must web publish the whole thing as a application to the web server.
so this is the whole site. Things like custom logon providers, http handlers, and even trapping the Session() start can be done.
And When you web publish, then you get a standard web site, and folders and all of the SOURCE vb.net (or c#) files are removed. Just like compiling down and deploying any desktop application - the source code and files are REMOVED. Needless to say, this approach is "common" to developers coming from a desktop environment.
So no sub-sites really can be done with this model. You are hooking DIRECTLY into the IIS web server.
A web site?
That is ONLY a set of folders that you can have the IIS site work against. In fact one could argue that AFTER you publish a web application, you get "mostly" the SAME thing as a web site.
But this model with any ease cobble up a web site with say 5 pages and JUST deploy that to your local web hosting? Nope!!! - can't do that!
The reason of course is you NOT dealing with ready made web site layouts and files. You HAVE to compile the whole mess into a application.
So like deploying an desktop application you are deploying a WHOLE system.
Now, if you going to have a site with say user logons, passwords and write a custom authenticaiton provider that IIS will respect and use? Again a web site can't do that.
So again you need a code system that supports logon hooks, and lets you control what those people can see and do. So for a line of business application? Well that quite much going to be a whole system - and thus you need control of logons, a master page(s) etc.
So the root, the config files, how they EVEN logon to your site? Everything must be just right and that config setup and file is the BASE SITE configuration for the web server. You can change authnetical providers - include custom http handles etc.
So this is a whole custom site here. And as noted, this is publish type operations.
However, asp.net for a long time ALSO supports what is called a web site.
So when the web started? Well, you just dumped web pages into some folders - maybe some hyper links to jump around. But a LOT of developers started out working this way. And because you can DIRECT edit the files and save them back to the site? Then no real concept of a application compile or even a web publish exists in this context. It just files sitting in a web ready format and a simple set of folders.
So a asp.net web site = just folders and files - no publish.
Now for one small change, no question that a web site is nice. And BETTER is that you can say take a set of folders and just DROP them into a existing web site - your not really publishing anything, so like the old days, you just edit and copy files to the web server folders and they work. This of course common fair html files.
But IIS does support using aspx pages (files) this way also!
Since this is just SOME folders with web pages? Then you can create and build say a bunch of different folders - each having their own cute little mini-web site. And this means that publishing to your cheap $8 per month asp.net hosting is possbile. You don't need a full IIS server and the ability to manage the IIS server system. All you EVER do is just copy files to the web site. Nothing more, nothing less. As a result, you don't have use of Session() start, and even the logon events are not under your control (unless of course you rolled your own and don't use IIS security.
With simple files and folders? Then your $8 hosting site can be used.
However, all if not most low cost simple hosting sites don't support asp.net applications.
So you can think of a web publish as replacing your base web application system the hosting provider gives to you. it also why you do NOT get use of the full ASP.net and IIS configuration options for the web site (your web provider controls and has that!!!).
One huge benefit of web sites is ease of change. As noted, you can point VS to directly edit even on the live web site files!!! There is really not concept of publishing - you just editing files and saving them to the web site folder. And this is really nice for a small change - the web site will re-compile the code for you, and for a large site, you can make a change to one wee bit of code behind and the web page - just copy that page and code to the site and you are DONE!!!
With a web application? you are doing a full-re compile, re-publish to the site for ANY and all changes. (well, ok, you could sneak in and say edit/change some markup on web page, but for the most part anything that messes with controls on a page would and could very easy break the compiled .dll's that are driving that page.
do you suggest I use WebForms or MVC?
That is a huge deal. MVC does not even have a visual designer for your web pages (you can only see and write markup).
And the whole MVC code model and whole event model is VERY different. So perhaps while a great idea to adopt MVC? (it is!!), it is darn near a whole re-write of your existing site - they work very different from asp.net webforms applications.
to a server via TCP/IP connection (TCPClient), and handles all requests and commands through my own custom protocols
If you mean custom http handlers? No, web sites don't' support this, you have to be creating a web site application. You can't by a simple act of placing some web pages on a web site have the lower level http handlers and network stuff change - you can only do that with a web application. Same goes for the authentication provider(s) you choose - simple web sites don't allow you to build your own custom providers (but you can roll your own logon system from scratch - but you not then enjoy even simple setups that automatic secure web pages based on their memberships in given security roles.
Currently we have a bunch of web sites (web site projects) that I think should be converted to web application projects. Everybody agrees.
But a number of custom BuildProviders are used to generate controls and unfortunately MSDN says that
Adding a customized BuildProvider class to the Web.config file works in an ASP.NET Web site but does not work in an ASP.NET Web application project
Are there some ways to migrate though without full discarding of custom BuildProviders mechanism?
Without knowing exactly what your build provider do I can see two possible solutions:
Custom MSBuild tasks
T4 templates
Hey you need to implement, a custom IVsSingleFileGenerator.
And register it with your VS, to generate a custom .designer-File.
The way DesignTime-Compilation works changed with Web Application Projects.
In combination with a BuildProvider you will get the same as ASPX-Pages.
I used it to generate user-interfaces with partial-methods to implement behavior in a codebehind-file.
That's impossible without review of the whole approach.
We have a web site built as an 'ASP.NET Website' type project, rather than the 'ASP.NET Web Application' type.
Aside from the obvious debugging advantages that the app type offers and access to the designer files for each page:
What, if anything, can be gained by switching from website project type to app?
Are there performance losses with one over the other?
How much work is involved in switching an existing (dev) site from website to app? Is it as simple as creating another site as app type and adding these existing aspx files and libraries to it?
This question (How To Convert ASP.NET Website to ASP.NET Web Application) seems to cover the steps.
What are the risks (if any?)
How much work should we plan on?
Are there differences in how HTTP Application deals with requests or how handlers work between the two types?
Anything we forgot to think of?
http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
That describes some of the features and advantages/disadvantages between the two.
The main reason to use the web project versus the web site is that the web site is dynamically compiled which tends to incur a performance hit whereas the web project is precompiled. You should gain performance moving to the web project method. You also gain control over the naming of your final compiled assemblies.
The amount of work really depends on how many pages are in your old site.
I don't think the .NET framework handles code differently in the web site versus the web project. It's really the configuration of the file structure, the lack of a central project file, and the method of compilation that ends up being different between the two.
How ASP.NET compiles its assemblies generally confuses me. It seems that I cannot program against anything outside the App_Code folder. In the application I am working on I have several server side controls and a few user controls. The user controls are outside the App_Code folder and I cannot refer to them from the App_Code folder. It is a "Web Site" project.
How can I refer to the UserControls from the App_Code directory?
Is this a compilation issue?
Thanks in advance.
Yes, it is a compilation issue, read a bit more about this same question at
http://www.velocityreviews.com/forums/t119801-accessing-web-user-control-from-class-in-appcode-folder.html
Whilst I'm sure suggesting you convert the web site to a web application is something you have considered doing and rejected, it may be the way forward if accessing your user controls is something you're looking to do frequently.
The way that I have gotten around the app_code issue is by putting all of my classes into a separate project and include the dll from that project as a reference in the web project. That also allows me to reuse the classes in other applications. I believe this is a common practice for business logic and data access when building an application using an n-tier environment.
Are you sure you're referencing the namespace which contains the user controls?
Is there any difference between website and web application project? What if you are working on a project that is sort of hybrid of site and application? which project should you chose?
I'ld go the newer Web Application project (always, regardless of the size of the project).
There is nothing to lose and everything to gain with using the Web Application Project (you cannot say this about using the "website" only).
The official list of differences are here:
Use Web Application Projects when you
Need to migrate large Visual Studio.NET 2003 applications
Need to
control names of output assemblies
Need stand-alone classes to
reference page and user control
classes
Need to build a Web
application using multiple Web
projects
Need to add pre-build and
post-build steps during compilation
Use Websites if you:
Need to generate one assembly for each page.
Prefer single-page code model to code-behind model.
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).
Want to open and edit any directory as a Web project without creating a project file
#Mehrdad's link here is essential if you want to know more http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
As for which project to choose, I would go with the Web Application Project, regardless of size. Having all of your code behind compile down into a single DLL is a major benefit for maintenance and security on the hosting end. I know there are precompile options for web site projects, but they seemed like more trouble that it was worth for me.
I know that the IIS filters are in place to prevent users from accessing your .vb or .cs files, but it still makes me a little leery.
But more important to this is the nice fact that if you make a bunch of coding changes, or maybe add some classes and change the processing logic, the only thing you have to merge up is the compiled DLL and nothing else. Similarly, if you do a few UI changes (say change the stylesheet or position of a few controls), you don't have to worry about recompiling the application, you simply bring over the update .aspx page and you're done.
Take a look:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
http://forums.asp.net/p/1300026/2538628.aspx
I'm used to create websites when I want to create a new webapplication.
My current project had some problems on compiling, so I switched to a webapplication project. The step isn't very hard. Visual Studio helps you to change all necessary lines.
Refer to the links in the post:
http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Anthony :-)