We've been working on an application that quite heavily relies on VirtualPathProviders in ASP.NET.
We've just come to put the thing on a live server to demonstrate it and it appears that the VirtualPathProviders simply don't work when the site is pre-compiled!!
I've been looking at the workaround which has been posted here: http://sunali.com/2008/01/09/virtualpathprovider-in-precompiled-web-sites/, but so far I haven't been able to get that to work, either! (Well - it works fine in visual studio's web development server - just not on our IIS box - again!).
Does anybody here have any more information on the problem? Is it fixed in .NET v3.5 (we're currently building for v2.0)?
Unfortunately that is not officially supported. See the following MSDN article.
If a Web site is precompiled for deployment, content provided by a VirtualPathProvider instance is not compiled, and no VirtualPathProvider instances are used by the precompiled site.
The site you referred to is an unofficial workaround. I don't think it's been fixed in .NET 3.5 SP1
Related
Which version of Visual Studio can be used to open a project which is built as ASP Web project
I have Community edition 2019 Does this support ASP projects?
I know these days no one is using ASP for building web apps The purpose is to maintain an existing ASP solution for a couple of more months 9If any bug fix requests from the client comes ) and start to build a new project using the latest version of Microsoft technologies
Visual Studio
Most versions of Visual Studio support editing Classic ASP code, couple of things to keep in mind though.
Frontpage Server Extensions is no longer supported, the best approach is to use a mapped drive or better yet store the code in source control (Git, SVN etc.) and work with the code locally (can bind to a local instance of IIS).
The IDE can be quite cumbersome for working with Classic ASP as it's designed for more modern technologies.
It also has sophisticated debugging through the IDE via the "Attach to process" which will work with Classic ASP running in IIS as long as the web application has been configured correctly for debugging. See How do you debug classic ASP?.
Visual Studio Code
Another option is Visual Studio Code which is a free IDE built on the principle of open source projects for cross-platform. It's becoming a popular free IDE for many developers rivalling the likes of Atom, Sublime etc.
It's lightweight and extensible through extensions, there are already some useful extensions for Classic ASP including this one;
Name: Classic ASP Syntaxes and Snippets
Description: Classic ASP Language Support and Snippets from tmBundle
Publisher: Jintae Joo
It also has built-in support for popular source control solutions like Git and more powerful available through the extension marketplace that is built into the IDE. If you do use Git would recommend installing the GitLens extension.
Every version of visual studio since I started with 2010 (was there something before it?) handles Classic ASP just fine. I'm on VS2019 right now.
I even have a project which is a combo Classic ASP, Webform, and MVC all in one project, with some session sharing, and I routinely code and debug in all. The only limitation is that when you debug, you have to choose whether you're debugging Managed code or "script".
With each I "attach to process" and choose which code I want to debug. Classic ASP debugging is fantastic, and I can't believe more people don't do it. I see basic questions on here which would easily be fixed with standard debugging techniques (settings breakpoints, evaluating variables).
The ONLY thing which isn't supported is code formatting inside <% %> blocks. If I ever get some time maybe I'll make an addon for it.
A Little Background:
My team has a somewhat outdated ASP.NET MVC solution that I have been tasked with upgrading as current as possible. We're migrating up from MVC 2 and WebPages (ASPX/ASCX) to MVC 4. The solution is rather large (20+ projects) and most of it is working properly. We have run into an issue though where some of the aspx pages throw the compiler error:
> "BC30456: 'InitializeCulture' is not a member of 'some_extended_view_name_here'...
Most of the digging I came up with on the issue recommends that when publishing, you unselect "allow this precompiled site to be updatable". Problem is that when running locally via the "Run/Run Without Debugging" buttons, you aren't publishing per-se. So...
TL/DR: Is there any way to change the 'publish' settings when using the run or run w/out debugging buttons for MVC websites in Visual Studio 2012/2013? I have looked and looked, but can't find anything suggesting it's even possible.
I am currently working on an sharepoint 2007, web application and I am trying to create an MVC 3 site inside the same website which runs on .Net Framework 4.0 (Integrated Mode).
Initially we had issues to get it working as web.config (for the main site[Sharepoint 2007]) had dlls registered for .net framework 2.0, even for the MVC 3 application. We got this problem resolved by updating the web.config in the .Net Framework, so right versions on dlls where registered for .Net 2.0 and 4.0.
The problem was solved and I was able to get to the MVC and main site without any issues, now all of a sudden, after restarting my VM, when I visit my the main site, a DLL is served (yes, browser downloads a dll file !!).
This is the case with 3 other colleagues of mine. Any expert advice would be very helpful.
Thanks
Uff ! After a days of staring at IIS and extensive googling, it turns out giving 'Execute' permission to handler mapping for _vti_bin folder resolves the problem. I am surprised no one had this issue before, or may be it could be something to do with out rake script (deployment package- script).
Anyways thanks to all those who viewed my question. Hope this answer helps someone !
one thing is not clear to me that in asp.net 1.1 there was asp.net project type but from 2.0 version there is no asp.net project type option rather there is option called website type project.in website type project no link is created with IIS.why Microsoft design in this way from 2.0 version. i think there must be solid reason & advantage behind it and also tell me why no dll is created in bin folder until publish the website in version 2.0.
please explain the reason,advantage and MS Thought behind it if anyone knows the reason very well.
With ASP.NET 2.0, Microsoft split the concept into two different project types: the Website project type you're describing, and the Web Application project type. The main difference is the Website project type is designed to be folder-based, lightweight, JIT - essentially low-overhead where no overhead is justified. The Web Application project is a "traditional" project type: assembly-based, with a project-schema and optimized for precompilation.
In my experience the Website project type is unpopular with developers, perhaps for no other reason than it is different from almost every other project type. The limitations should theoretically make quick-and-dirty website projects more agile, but frankly I don't find the overhead of a Web Application project a concern.
MSDN covers the differences between the two here: http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
Because they forgot to add the template. That bug was rectified in SP1.
Besides, there are now two types: website + web application. Use the latter if you can, because website projects don't offer installers.
I've recently started playing around with ASP.NET and I was just about to connect to a database using LINQ, when I realised that you have to change a bunch of stuff in the project first if you created a normal web site project in Visual Studio 2008.
All the information about LINQed projects in VS2008 that I have found start directly from scratch with a completely new web site. What modifications do I have to make to my project to be able to make use of LINQ?
I think that your question can be answered by viewing this post on stackoverflow.com.
In short your application will need to have access to System.Linq which comes from the .NET 3.5 framework. If your application is currently using .NET 2.0, it is possible to hack a setup with the CTP packages for Linq prior to it being released with Visual Studio 2008, but you might find it hard when you push your application out to production to a hosting company because you will have to install .dll's into areas you generally don't have access too.
Good luck on your conversion to Linq.