Recently I had to add a whole bunch of .NET assemblies to an ASP.NET MVC project. I am not kidding when I say it were about 60 DLL’s. Instead of adding all those files separately I was wondering if it was somehow possible to merge those files into one.
After a short search I found a free tool from Microsoft Research called ILMerge.
Here’s the command for merging all (.NET framework v4) DLL’s in the current working directory into a single DLL file:
1 | ilmerge /wildcards /t:library /targetplatform:v4 /out:Framework.dll *.dll |
And here’s the direct download link:
http://www.microsoft.com/en-us/download/details.aspx?id=17630
Would be nice to see this stuff integrated in Visual Studio…
Recently a couple of serious security issues (see CVE-2013-0155 and CVE-2013-0156) have been discovered in the Rails framework, leaving practically all versions of Rails vulnerable to attack. To my surprise, even the Dutch government owned DigID (an identity management platform which government agencies of the Netherlands can use to verify the identity of Dutch citizens on the Internet) was using Rails and had to temporarily shutdown its service until the security hole was plugged.
Since I maintain one Rails 3.1 application on a production server I needed to upgrade to 3.1.10 as well. Simply installing Rails 3.1.10 will NOT be enough! You will have Rails 3.1.10 with the security fixes installed on your system, but your Rails application will use whatever it has in the Gemfile.
Here’s how to migrate to 3.1.10 (or later):
In your Gemfile you will see a fixed version, e.g.:
source 'http://rubygems.org' gem 'rails', '3.1.0' # rest of file omitted
Change ’3.1.0′ or whatever you have there so it reads:
source 'http://rubygems.org' gem 'rails', '~> 3.1.0' # rest of file omitted
The ‘~>’ means to use 3.1.x, currently this would use 3.1.10, since that’s the latest stable version within the 3.1 release branch. In theory, you shouldn’t have to worry that upgrading might break things, since 3.1.10 (or later) should be backwards compatible with any previous 3.1.x version.
Now you update Rails using:
sudo bundle update railsBe sure to redeploy and/or restart your Rails application and you’re set!
If you have previously used `bundle pack` to include gems as part of your deployment (in the vendor/cache directory), than those two will be automatically updated.
In case you run into a Ruby compile error, this is probably because you have an outdated version of Ruby.
You might see e.g.:
Fetching source index for http://rubygems.org/ /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash': bignum too big to convert into `long' (RangeError) from /usr/local/lib/site_ruby/1.8/rubygems/requirement.rb:109:in `hash' from /usr/local/lib/site_ruby/1.8/rubygems/specification.rb:1308:in `hash' ...
You can either upgrade Ruby to a higher patch level or patch it yourself. More info here.
Hope this helps someone.
Almost two weeks and 50 commits later since the last post. A lot of spare time has been spent on Ruby hackery. 
Long story short, we now have a parser, (re)written in Ruby, which can parse IRC logfiles in either Eggdrop or Irssi logfile format and save the parsed lines to a MySQL database. The Rails web application basically consists of three pages: 1) the logfile index page 2) the logfile detail page and 3) the search page. Search is powered by a lightning fast search engine called Sphinx.
Some remarkable features:
- The parser can parse a single IRC logfile (in Eggdrop or Irssi format), a whole directory or a subset (when using a mask).
- The logfile index page shows a list with links to the top 25 most recent log files, in chronologically reverse order.
- The logfile index page is paged and when JavaScript is enabled in the browser it acts as an endless page, meaning when you scroll down more and more links to logfiles are shown.
- The logfile detail page has links to the previous and next logfiles and is pJAX enabled, meaning you get a faster browsing experience by not reloading the entire page.
- The web application comes with page output caching enabled by default. Making subsequent calls to a previously generated logfile page as fast as possible.
- Each line on the logfile detail page has a timestamp which acts as an anchor. This makes it easy to link to that specific line.
- Search is powered by Sphinx search engine, which is extremely fast at indexing and searching.
- Clicking on a search result will redirect you to the logfile detail page at the correct line (using anchors) and the search keyword will be highlighted as well.
- Automatically redirected to the logfile detail page when there was exactly one search result.
- The nick names on the logfile detail page are colorized so it’s easier to follow the conversation. Colors are preserved when someone changes his or her nick.
- Chat messages from the same nick are grouped as long as no other events have occurred.
Known issues/limitations:
- Supported timestamps are limited to hours and minutes.
- Search and highlighting is currently limited to one single keyword.
- Nick colorizer currently only supports up to fourteen unique colors.
- No page output cache expire methods have been implemented yet.
- Eggdrop and Irssi are the only two currently supported logfile formats.
- MySQL is the only supported database back-end.
- Not a lot of error checking, also no custom error pages or exception notification yet.
The above issue and limitations, as well as new features, will be resolved in the future of course.
The source code can be found on GitHub:
When I was trying to install the IRC Collective parser onto my Debian home server I ran into some issues which are the result of not maintaining the source code. It has been roughly four (4!) years ago since the last commit (February 3rd, 2009). The ConfigFile module was deprecated and I couldn’t figure out how to implement its successor. My Perl was very rusty, since I don’t normally program in Perl and it seems I’ve used quiet some Perl shortcuts in the source code, which I have forgotten over the past few years. Perl is known to be “write once, read never”.
Since I have been doing a lot of development with Ruby (and Rails) lately, I pondered if I could easily rewrite the core parts of the parser (parse an IRC logfile and store the parsed lines to a SQL database). One of the preconditions was that I could reuse the regular expressions from the Perl version. After a quick test it seemed it would work!
The Ruby version currently parses Eggdrop and Irssi logfile formats and can store the parsed lines in a MySQL database. Support for other logfile formats and SQL databases will be added later.
The source code (which is a lot more object oriented and DRY) for the new Ruby version of IRC Collective, can be found on GitHub:
https://github.com/rmatabadal/irc-collective-ruby
The next step is to create a nice Rails web application for viewing the logfiles and searching through them…
Happy new year!
As of September 2012 I am officially a certified software engineer!
Diploma software engineering
So glad I can finally close this chapter!
