We have to maintain a lot of classic ASP and VB/ASP.Net applications that link to many different parts of a static website.
The master pages are littered with various
<!-- #include virtual="/site/footer.something" -->
and similar, where there are many many combinations of what /site/ can be.
The problem is, when you're debugging etc. when you try to run one of these sites locally, you're almost guaranteed to get a parser error.
What I want to do is come up with a generic handler so that I can just insert a blank file for any #include file that doesn't exist.
I tried to setup a URL Rewrite rule, which works in the browser (just redirects to an empty html file) but I'm guessing the ASP parser doesn't include as a webrequest as it still generates a parser error.
I don't want to have to copy the static content to my workstation everytime I open a new app and I don't want to edit the master pages to exclude the links as one day I'm just going to forget and deploy something broken.
So the question is, is there a way to serve a default file for these declarations, or some other method ?
Edit: To consider a different fix to this problem; is there some way to insert some kind of file-system handler that can pick up requests for missing files in specific locations and return predefined content ?
Yeah, I know that's a really offbeat direction and probably a very bad idea in practise, but this is quite a frustrating problem in the office now.
What's irritating is that even though IIS has SSI disabled, the ASP processer still honours #include directives. Is there a way to either disable that, or perhaps some way to override the behaviour in some kind of generated class ?
The problem you will encounter is that includes are processed before any of your code runs. The server gathers all of the resources referenced in the scripts then compiles and runs your code. By the time your code is running, the missing include has already thrown a compiler error.
Further, what you're asking could potentially run into other problems. Often times includes contain code (procedures, constants, variable declarations, etc.) that other scripts rely on. So, even if you were to replace the missing include with an empty file, you still may encounter other parser errors if the including script expects that include to contain specific code.
Probably your best bet is to make a console app or something similar that parses your files looking for the include statements, resolves the relative path based on your directory structure and does what you want - write an empty file if it doesn't exist. You could then run your projects through this parser and at least eliminate that issue.
Additionally, you mention the possibility of accidentally deploying something that you've edited to circumvent this problem. I would assume then, that if you were to write out these "dummy" includes, there is no possibility of you accidentally deploying them and overwriting good files?
Related
After about a week of tinkering, I have managed to introduce webpack and Vue.js single file components into my existing Orchard (ASP.NET) module.
Now I've unexpectedly hit a snag, and for the life of me, I'm stumped. I have several image resources that are part of my custom Orchard theme, which is a separate module (*.csproj) within my Orchard solution.
So (at the risk of demonstrating my woefully inadequate understanding of URL concatenation in web projects) I innocently add this line to my Vue.js single file component:
<img src="~/Themes/MyOrchardTheme.Theme/Images/AnImage.png">
Now when webpack tries to process this and bundle my component I get this error:
Can't resolve 'Themes/MyOrchardTheme.Theme/Images/AnImage.png' in 'redacted' C:\Projects\Orchard\Modules\redacted\Module not found
This kind of makes sense, because the layout of my projects and resources locally and the layout after deployment to Azure obviously differ.
So what is the right way to specify the url for my image as it will exist at runtime on the server, without specifically testing for it's existence when transpiling with webpack?
I'm not going to accept this as the answer, in case someone can offer something better, but after some tinkering I was able to solve my problem by using this:
<img :src="theimage" />
and adding a computed property like this:
computed: {
theimage: function () {
return '/Themes/MyOrchardTheme.Theme/Images/AnImage.png';
}
This will bypass the Webpack transpiler (or vue-loader or whatever) check to make sure the resource can be located and has the added benefit that I can programmatically control the image displayed, which (although not mentioned) is ultimately what I wanted to do (code not shown). I was expecting to use v-if or v-show with multiple image tags, but using a computed property killed two birds with one stone.
Thanks to everyone who provided feedback. - I have a great deal to learn!
I have a lua project with lua files specified in multiple directories all under the same root folder with some dependencies.
Occasionally I run into issues where when a table is being loaded at load time I get a nil exception as the table is referencing a not yet initialised table, like:
Customer =
{
Type = CustomerTypes.Friendly
}
Which causes a nil exception for CustomerTypes as CustomerTypes.lua has not yet loaded.
My current solution is to simply have a global function call in these lua files to load the dependency scripts.
What I would like to do is pre-process my lua files to find all dependencies and at run time load them in that order without needing function calls or special syntax in my lua files to determine this (i.e. the pre-processor will procedurally work out dependencies).
Is this something which can be realistically achieved? Are there other solutions out there? (I've come across some but not sure if they're worth pursuing).
As usual with lua there are about 230891239122 ways to solve this. I'll name 3 off the top of my head but I bet I could illustrate at least 101 of them and publish a coffee table book.
First of all, it must be said that the notion of 'dependencies' here is strictly up to your application. Lua has no sense of it. So this isn't anything like overcoming a deficiency in lua, it's simply you creating a scripting environment in your application that makes you comfortable, and that's what lua's all about.
Now, it seems to me you've jumped to a conclusion that preprocessing is required to solve the given problem. I don't think that's warranted. I feel somewhat comfortable saying a more conventional approach to solving the problem would be to make a __newindex metamethod globally which handles the "CustomerTypes doesnt exist yet" situation by referencing a list of scripts which have been scanned out of the filesystem initially for one called CustomerTypes.lua and running that.
But maybe you have some good reason for wanting it done strictly as preprocessing. In your case, I would start by considering 'dependencies' to be any name which is a script found in your scripts filesystem. Then scan each script to look for the names of dependencies using the definitions/list you just created, and prepend a load(dependency) command to each of those scripts.
Since the concept of "runtime" or "preprocessing" is somewhat ambiguous in this context, you might mean at script-compile-time. You could use the LuaMacros token filters system to effect a macro which replaces CustomerTypes with require("CustomerTypes.lua") or something to that effect after having discovered that CustomerTypes is a legal dependency name.
This is a (actually it is several) follow-up question to my previous question on F# Type Providers and Continuous Integration.
It seems to me that it would be a good idea to use the SqlDataConnection type provider as a compile-time check that the code/database integrity remains intact in feature-branch driven development; you would know at every commit/build that no changes have been made to the code that has not also been applied to the database, assuming that building the database is also a part of your CI process.
However, a couple of questions arise:
The name (as well as the location) of the config file is not the same at compile time as at runtime, e.g. app.config -> MyApp.exe.config, which will result in a runtime error if you try to use
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
(Actually, specifying ConfigFile="app.config" is not necessary, since it is the default value.)
The runtime error can be avoided by copying the app.config file to the output directory (there’s a setting for that), but that would result in having both an app.config and a MyApp.exe.config file in the output directory. Not very pretty. Adding a separate configuration file for type providers would be another solution, but imho that’s not very pretty either.
Question: Has anyone come up with a more elegant solution to this problem?
The next problem arises when you come to the build server. It is most likely that you don’t want to compile against the same database as you did while developing, thus requiring a different connection string. And yes, in production you’d need yet another one.
Question: How do you go about solving this in the most convenient way? Remember, the solution has to be a working part of a CI process!
This strategy would require generating the database on each build at the build server, probably from a baseline script with some feature/sprint update scripts.
Question: Has anyone tried this and how did it affect build times? If yes, how did you create this step?
At runtime you can use the GetDataContext overload that accepts a connection string. See here: Providing connection string to Linq-To-Sql data provider
I am familiar with the solution that #Gustavo proposes, but I’ve always felt that there is something fishy about it. Something about having to specify the connection string twice… However, when I once again got the same reply, I slowly started to realize that the answer must be correct, and that it’s me who’s thinking wrong. These are my conclusions:
The reply states that you can use the GetDataContext overload that accepts a connection string. If you change this to should, things become clearer, at least to me.
The thing is that I’ve been thinking of the class definition as both a compile-time directive and as a run-time variable, but even though this is possible, it is hardly a good idea. The default value of the ConfigFile argument is as we’ve already seen “app.config”, but that file doesn’t exist (with that name) at run-time, so it doesn’t make sense to try to use it, thus leaving GetDataContext as the only reasonable option. I suggest that you do this:
Keep your compile-time settings in a file called compilation.config (or whatever you prefer) and specify this file for usage in the class definition.
Use the GetDataContext overload that accepts a connection string for run-time resolution and specify this connection string in the app.config file.
You will end up with something looking like this:
type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)
Heck, this even supports the SRP; compile-time settings in one file and run-time settings in another!
Regarding the rest of my questions, I assume that the answer lies in some scripting in the Continuous Deployment pipeline. Still interested in other solutions though.
In my web project, I have a custom IControllerFactory that uses StructureMap to build my Controller instances. The factory works exactly as it should, and the website responds perfectly, however, the event log ends up getting flooded with messages that look like:
The IControllerFactory 'MyCustomNamespace.StructureMapControllerFactory' did not return a controller for the name 'fancybox'.
This is just one example, but there are others for static resources (css, js, images, etc.) beyond just the 'fancybox' stuff. All these errors make it difficult to track down real problems, because it's difficult to find problems among all the noise, so my question is, has anyone come across this issue before, and if so, how did you configure the site to avoid these errors cluttering up the EventLog?
TIA, -J
This is an old question but I've recently run into the same issue, the problem was that there was a PNG image referenced in two CSS files that did not exist on the disk and weren't used by the application. Removing the references from the CSS fixed the issue.
In the Event Log, scroll down to where it tells you the request URL and check to make sure the item (image, script, style-sheet etc.) actually exists.
Background
We have an existing webapp, built with Struts 2 and Freemarker, of which I’ve created a variation by copying some of the code and templates. Kludgy, but manageable. We will however soon be making quite a few other variants (which need to be individual WARs), making copying untenable. My thought is to instead put all the shared stuff into a jar included with each webapp: the common files could be maintained in one place, and even better a given webapp could override files from the classpath. So far I've been able to do this with the code, but the Convention plugin is making it difficult to do the same for the Freemarker templates.
Problem
Thus far our webapp has relied on Convention to find the Freemarker “action results” (i.e. templates) for actions at application start-up, saving us from having to tediously annotate each of them. If I've traced things correctly, the class DefaultResultMapBuilder is responsible for finding the actions results; in particular, the method createFromResources looks in the webapp and then on the classpath for template files matching our actions.
This is exactly what I want – except that we put our templates under /WEB-INF to protect them from outside access (using the struts.convention.result.path constant in our Struts configuration). This has worked fine until now, with ALL template files located under /WEB-INF, but it’s not working with files also on the classpath. DefaultResultMapBuilder can certainly find files on the classpath, but only when webapp templates are under the context root directly, as any classpath templates have to be in a package structure equivalent to the directory structure of templates under the context root. For action results to be found when “struts.convention.result.path" starts with “/WEB-INF/” would require a root package called “web-inf” – but of course hyphens are not allowed in package names.
(Note that this issue is independent of the TemplateLoader classes that are later used to actually grab the template files. The loading process is readily configurable to look in many places – but the app never gets that far if the ‘action results’ are not found at startup. It would be nice if both processes used the same configuration...)
Solutions?
So… I could move all our templates outside of /WEB-INF but really I’d rather not. Or I could provide specific annotations for each action class, and again I’d rather not (and indeed it might suffer from the same issue).
Or I could make my own implementation of ResultMapBuilder by copying and very slightly changing DefaultResultMapBuilder (every member in the latter is private, so I can't extend the class and change just the relevant parts – alas!), and then figure out how to override the "struts-plugin.xml" Struts config file (to change the org.apache.struts2.convention.ResultMapBuilder bean), and thus I could get Convention to ignore "/WEB-INF" when looking on the classpath. Or perhaps better, to always prefix the path with "/WEB-INF/" when looking in the ServletContext.
But maybe there's an easier way? Some undocumented bit of configuration magic?