Does anyone know of an alternative to using the VirtualPathProvider?
I am using .Net 4.0, MVC3, Razor and webforms views, precompile deployment.
Was using VirtualPathProvider and VirtualFile to override the virtualpath and pull select views from database. If virtual path is not found in the database then default to the classes implementation (pull from the filesystem). This works great the first
time around, but if a view in the database is changed it is never found again. I am attributing this to precompilation, since if I delete the binaries and recompile the new view is then found in the database.
I see precompiled apps not allowing a VPP is sort of a security thing... but how many people precompile their apps today anyway? I don't run across many. So if you really need to precompile yet have the VPP do dynamic compliation (which seems like contradictory
goals) and it works, then go for it. I don't see Microsoft changing this for any reason.
What I am saying is that it does not work, even using the referenced workaround, that is the dilema. I see the work around is from 2008, which makes me wonder if MS has done something in the new version of the framework to keep this work around functionality
from working.
I am using a web application project which gets published for it's deployment hence it precompiles. Views, Scripts, Content stay intact but code is compiled into a dll. This is the current state of the application and it is unreasonable to change into a
different project type this far into the development process.
What I am trying to find out is two fold; one is there a known alternative method to accomplish the same thing using something other than VirtualPathProvider/VirtualFile, and two is there still yet a way to maybe get this to work in a precompiled environment.
I am not sure I understand your comment about the security implications. Could you please explain to me how this could become a security issue? I am having a difficult time understanding why precompiling an assembly is affecting the intended functionality
of overriding these classes.
If I a cannot use it that is fine, but I would just like to understand a little more clearly on the why. It sucks to invest some time into something only to find out it does not work, without finding a good reason why. (Just a little bi*%!ing there).
Thanks
If this post has helped you please mark as answer.
I am using a web application project which gets published for it's deployment hence it precompiles. Views, Scripts, Content stay intact but code is compiled into a dll. This is the current state of the application and it is unreasonable to change into a
different project type this far into the development process.
Hmm, unless the publish tool is doing something more than it used to, this is not precompile. Precompile is when you run aspnet_compiler.exe and the views and pages get "precompiled" before deployment into DLLs in ~/bin. You can confirm this by opening the
.aspx files and there should be no content inside.
aspfromatoz
I am not sure I understand your comment about the security implications. Could you please explain to me how this could become a security issue? I am having a difficult time understanding why precompiling an assembly is affecting the intended functionality
of overriding these classes.
Well, honestly I don't think it's a major security concern because the web server should be locked down properly anyway, but I think perhaps the reason for the precompile (and not just a compliation in visual studio -- i'm talking baout the proper aspnet_compiler.exe
precompile) was that some customers of Microsoft wanted some feature that prevented files being modified on the server and then being allowed to be dynamically compiled. This dynamic compilation is exactly what a VPP is for, so IMO it seems that those are
two different mutually exclusive goals.
So if all you're doing is a normal compile in Visual Studio and the .aspx files are deployed as-is, then you're not really doing precompile. And so then if your VPP isn't working, then I think you're running into some other problem. It's hard to diagnose
through the forum though, so I might be wrong.
You are correct. I had a misunderstanding of what precompile actually meant. After double checking my publish I have found that the views folder does have the original declarative markup templates (cshtml, I am using razor). It also has my content, scripts,
and bin folders. In the bin is one assembly for my web project and one for the entity framework.
So it appears the precompilation is not a factor in what is going wrong, that was a dumb mistake on my part. Sorry about that.
It gives me a little bit of hope that I may get this thing to work yet. I did go down the road of depency caching for a little bit but the changes I made for it had no affect either. No matter what I do in the browser (refresh, clear temp data, etc) after
I change the razor template in the database it never shows up in the website, unless I stop debug mode and delete the compiled assembly from the bin folder and restart the web app. When it has to recomplile all over it seems to use the VirtualPathProvider
I created and finds the custom code to go pull the razor view from the database table.
If you are interested in checking it out I can post the code that I am using this evening.
If this post has helped you please mark as answer.
It gives me a little bit of hope that I may get this thing to work yet. I did go down the road of depency caching for a little bit but the changes I made for it had no affect either. No matter what I do in the browser (refresh, clear temp data, etc) after
I change the razor template in the database it never shows up in the website, unless I stop debug mode and delete the compiled assembly from the bin folder and restart the web app. When it has to recomplile all over it seems to use the VirtualPathProvider
I created and finds the custom code to go pull the razor view from the database table.
Oh I see, so your problem is that your views are in the DB and if the DB changes then the rendered page is still the previous content. Yea, ASP.NET is caching the compiled DLL and just reusing it, so the VPP is never used again once it's compiled.
If I recall correctly, there's some API or event on the VPP that allows you to indicate that the origin of the view/aspx is changed/updated, but you'd have to figure out the infrastructure for detecting that between your VPP and DB.
It says the default implementation is to return null which infers no caching. I actually had to force a null to be returned so I could get it to work. I am also returning a file hash of the virtual path concatenated with the current date and time.
If this post has helped you please mark as answer.
aspfromatoz
Member
276 Points
98 Posts
Alternative to VirtualPathProvider Using PreCompile
Mar 23, 2012 02:37 PM|LINK
Does anyone know of an alternative to using the VirtualPathProvider?
I am using .Net 4.0, MVC3, Razor and webforms views, precompile deployment.
Was using VirtualPathProvider and VirtualFile to override the virtualpath and pull select views from database. If virtual path is not found in the database then default to the classes implementation (pull from the filesystem). This works great the first time around, but if a view in the database is changed it is never found again. I am attributing this to precompilation, since if I delete the binaries and recompile the new view is then found in the database.
I have tried the following work around...
http://sunali.com/2008/01/09/virtualpathprovider-in-precompiled-web-sites/
It reacts the same way as if I have registered the virtual path provider in the global.asax.
Is there a different way of accomplishing the same task with different tools or is there a new workaround to be used for .net 4.0?
BrockAllen
All-Star
27522 Points
4901 Posts
MVP
Re: Alternative to VirtualPathProvider Using PreCompile
Mar 23, 2012 02:42 PM|LINK
I see precompiled apps not allowing a VPP is sort of a security thing... but how many people precompile their apps today anyway? I don't run across many. So if you really need to precompile yet have the VPP do dynamic compliation (which seems like contradictory goals) and it works, then go for it. I don't see Microsoft changing this for any reason.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
aspfromatoz
Member
276 Points
98 Posts
Re: Alternative to VirtualPathProvider Using PreCompile
Mar 23, 2012 06:14 PM|LINK
BrockAllen,
What I am saying is that it does not work, even using the referenced workaround, that is the dilema. I see the work around is from 2008, which makes me wonder if MS has done something in the new version of the framework to keep this work around functionality from working.
I am using a web application project which gets published for it's deployment hence it precompiles. Views, Scripts, Content stay intact but code is compiled into a dll. This is the current state of the application and it is unreasonable to change into a different project type this far into the development process.
What I am trying to find out is two fold; one is there a known alternative method to accomplish the same thing using something other than VirtualPathProvider/VirtualFile, and two is there still yet a way to maybe get this to work in a precompiled environment.
I am not sure I understand your comment about the security implications. Could you please explain to me how this could become a security issue? I am having a difficult time understanding why precompiling an assembly is affecting the intended functionality of overriding these classes.
If I a cannot use it that is fine, but I would just like to understand a little more clearly on the why. It sucks to invest some time into something only to find out it does not work, without finding a good reason why. (Just a little bi*%!ing there).
Thanks
BrockAllen
All-Star
27522 Points
4901 Posts
MVP
Re: Alternative to VirtualPathProvider Using PreCompile
Mar 23, 2012 07:40 PM|LINK
Hmm, unless the publish tool is doing something more than it used to, this is not precompile. Precompile is when you run aspnet_compiler.exe and the views and pages get "precompiled" before deployment into DLLs in ~/bin. You can confirm this by opening the .aspx files and there should be no content inside.
Well, honestly I don't think it's a major security concern because the web server should be locked down properly anyway, but I think perhaps the reason for the precompile (and not just a compliation in visual studio -- i'm talking baout the proper aspnet_compiler.exe precompile) was that some customers of Microsoft wanted some feature that prevented files being modified on the server and then being allowed to be dynamically compiled. This dynamic compilation is exactly what a VPP is for, so IMO it seems that those are two different mutually exclusive goals.
So if all you're doing is a normal compile in Visual Studio and the .aspx files are deployed as-is, then you're not really doing precompile. And so then if your VPP isn't working, then I think you're running into some other problem. It's hard to diagnose through the forum though, so I might be wrong.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
aspfromatoz
Member
276 Points
98 Posts
Re: Alternative to VirtualPathProvider Using PreCompile
Mar 23, 2012 09:09 PM|LINK
BrockAllen,
You are correct. I had a misunderstanding of what precompile actually meant. After double checking my publish I have found that the views folder does have the original declarative markup templates (cshtml, I am using razor). It also has my content, scripts, and bin folders. In the bin is one assembly for my web project and one for the entity framework.
So it appears the precompilation is not a factor in what is going wrong, that was a dumb mistake on my part. Sorry about that.
It gives me a little bit of hope that I may get this thing to work yet. I did go down the road of depency caching for a little bit but the changes I made for it had no affect either. No matter what I do in the browser (refresh, clear temp data, etc) after I change the razor template in the database it never shows up in the website, unless I stop debug mode and delete the compiled assembly from the bin folder and restart the web app. When it has to recomplile all over it seems to use the VirtualPathProvider I created and finds the custom code to go pull the razor view from the database table.
If you are interested in checking it out I can post the code that I am using this evening.
BrockAllen
All-Star
27522 Points
4901 Posts
MVP
Re: Alternative to VirtualPathProvider Using PreCompile
Mar 23, 2012 09:58 PM|LINK
Oh I see, so your problem is that your views are in the DB and if the DB changes then the rendered page is still the previous content. Yea, ASP.NET is caching the compiled DLL and just reusing it, so the VPP is never used again once it's compiled.
If I recall correctly, there's some API or event on the VPP that allows you to indicate that the origin of the view/aspx is changed/updated, but you'd have to figure out the infrastructure for detecting that between your VPP and DB.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
aspfromatoz
Member
276 Points
98 Posts
Re: Alternative to VirtualPathProvider Using PreCompile
Mar 26, 2012 02:58 PM|LINK
BrockAllen,
Good call... I needed to override GetCacheDependency and GetFileHash which forces it to pull the virtual file from the database each time.
It is kind of strange though. If you refer the the instructions here...
http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.getcachedependency.aspx
It says the default implementation is to return null which infers no caching. I actually had to force a null to be returned so I could get it to work. I am also returning a file hash of the virtual path concatenated with the current date and time.