Here’s another ReactJS.NET quirk I ran into lately. While working on an ASP.NET site using the ReactJS.NET Nuget package to render content using React.JS server side we got this error message on the web server after deployment:
Cannot load V8 interface assembly. Load failure information for ClearScriptV8-64.dll:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4e3fedda\f5d1e0ef\assembly\dl3\68f03368\00cf5237_117bd201\ClearScriptV8-64.dll: Could not load file or assembly 'file:///C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4e3fedda\f5d1e0ef\assembly\dl3\68f03368\00cf5237_117bd201\ClearScriptV8-64.dll' or one of its dependencies. The system cannot find the file specified.
The annoying bit here is that everything works fine locally, but not when it was deployed to the server using an Octopus package.
After debugging, searching online and going through the build log files I figured out that the problems could be caused by :
- Missing DLL’s because of a missing Nuget package (quite obvious but not a problem in my case).
- The VS 2013 C++ Redistributables are not installed on the server, which is a common cause for this error related to the ClearScript assemblies.
In my case the problem was a variation of the 1st problem. Once the web app was published, the DLL files where not in the expected
bin\x32 sub-folders, but in the root of the application’s bin folder. So the DLL’s where there, but not in the correct spot.
The cause of this problem is the
_CopyWebApplicatonLegacy MS Build task which lives in the
This creates a
Because this task doesn’t get triggered in the step build to create the deployment package, the
ClearScript-V8-64.dll, v8-x64.dll & ClearScript-V8-32.dll, v8-x32.dll don’t end up in their x64 & x32 sub-folders.
I fixed this by moving the files to their rightful location while creating the package for Octopus deploy with a PowerShell script. There’s probably a way to fix this with an extra build tasks too, but man, I spent so much time on finding this issue in the first place and I really didn’t feel like getting myself into that mess as well.
Photo by Ted Van Pelt, cc-licensed.
Getting a web page using PowerShell is pretty easy using
Invoke-WebRequest. Getting a web page which is protected using basic authentication isn’t that much harder, but it took me a while to find out how to do that exactly as my initial searches didn’t turn up the right answers.
The trick is that you have to pass in a credential object when you make the call:
$result = Invoke-WebRequest http://foo.com -Credential $credential
$credential object is something you have to create. If you don’t pass in an object, you’ll get a prompt btw, which might also be handy.
Creating the object is done like this:
$user = "john.doe"
$password = ConvertTo-SecureString "a_password" -AsPlaintext -Force
$credential = New-Object PSCredential($user, $password)
PSCredential object is created and the username and a secure password string is passed into the constructor.
Putting the username and password in your script like this is a bad idea in a lot of cases, so you should really consider if this what you want to do. You can also use the
Get-Credential cmdlet to ask the user for the username and password instead.
That way you keep this sensitive data out of your script and make it more resilient to change as well.
This is all it takes to ask for the credentials and set them into a variable you use later on:
$credential = Get-Credential
Here’s another one for the error message Googlers. Recently I ran into a nasty build error on TeamCity after adding ReactJS.NET Nuget packages to an ASP.NET MVC solution.
Locally everything built just find, but on TeamCity the build failed with the following error message when trying to compile the MVC views:
[AspNetCompiler] ASPNETCOMPILER error ASPCONFIG: Could not load file or assembly 'ClearScriptV8-32.DLL' or one of its dependencies. The specified module could not be found.
Normally you get this type of errors when an assembly can’t be found or isn’t copied to the bin folder for some reason.
In this case it turns out to be more or less the opposite case. The DLL is in the bin folder, but .NET should be ignoring it. Apparently ASP.NET tries to load all DLL files in the bin folder, which it should not do for the v8 ones, making it crash and burn.
The clue came from this StackOverflow post and this blog post. The fix in the blog post is a bit hacky but pointed me in the right direction. The SO answer to change the web.config is spot on.
So the trick is to exclude the offending binaries by listing them in the web.config compilation section:
<trace autoflush="true" />
<remove assembly="ClearScriptV8-64" />
<remove assembly="ClearScriptV8-32" />
<remove assembly="v8-ia32.dll" />
<remove assembly="v8-x64.dll" />
This way the DLL’s are no longer automatically scanned, and your build can nicely go on compiling those MVC views without any trouble.
Photo by strange little woman on stream, cc-licensed.
One thing that annoyed me about using Vim was how much keystrokes it took to indent or un-indent a few selected lines of code. My (probably less than ideal) way of doing that was to go into visual mode, select the lines with the movement keys J or K, then use the keys to change the indenting which are
To indent another level, pressing dot after this would work.
In Visual Studio or a typical Windows text editor I’m used to simply selecting the lines by holding shift & moving the cursor keys up or down, then pressing TAB to indent and shift-TAB to un-indent.
I’m so used to using the cursor keys for text manipulation that it’s hard to unlearn this, so I was looking for key mappings to do the same thing in Vim.
Luckily this turned out to be rather easy. If you add the following to your vimrc file, you can shift-tab away to indent your code:
" TAB-mappings to allow indenting of selected text instead of using < & >
vnoremap <Tab> >
vnoremap <S-Tab> <
This is one for the “it’s easy once you know” category.
In the Firefox menu, go to Tools > Web Developer > Toggle Tools, or use the CTRL-I shortcut key to activate the developer tools side-panel. Once active you see one of those typical cog-wheel icons in the upper right corner showing the settings when you click it.
The “Disable Cache” option right above it is also a handy one if you are working on a page. It beats having to hit CTRL-F5 all the time anyway.
If you want an easier way to control this, store settings per site and things like that, you’re better off installing the NoScript plugin. There’s a reason this option is hidden in the developer tools after all.
Log files are dull to look at. Lines and lines of text and no pretty colors to make it nicer to look at and easier to spot those weird errors you can’t simulate on your machine.
Vim rocks and writing a syntax file is supposed to be a breeze judging from the vast amount of syntax plugins out there. I didn’t quite find one I liked for syntax highlighting HTTP log files, so I thought I’d get down and dirty with some vimscript myself and see if I could hack something together.
It turned out alright I think. So to share the fun I’m hosting the logsyntax.vim plugin on Github and the vim.org scripts library for all to use. It highlights dates, HTTP verbs, URLs, IP addresses etc for IIS, W3C extended, NCSA and probably a bunch more typical log formats.
May your logs be pretty and colorful from now on.
A while ago I noticed that some of my older posts had some silly misspellings in it, so I was looking for a way to spell check all my posts in one shot. I couldn’t really find anything that was free, so I figured I’d try to write something myself to do this for me.
I knew about the free and open source Hunspell spell checker and that you can use it from the command line. So I thought using that together with the WordPress export XML file which has all your post’s content it should be possible to spell check the whole lot.
The end result is a PowerShell script which reads out the XML export file and runs it through Hunspell, parses the spelling errors found and finally bundling it all into a simple HTML report.
It worked nicely for me, even though it’s pretty crude and simple. I only had to use this once, so I don’t see the point of fine-tuning it a lot further.
However this could be handy for others who want to do the same thing, so I cleaned it up a bit, slapped a readme file on it and posted it on Github as the WordPress full site spell checker.
Check it out if you want to spell check your WordPress blog in a single run and maybe this will be good enough to get your job done. You find more info on how to set up and use it on the Github page.