While working on a side project (Serial Key Maker) I explored the ability to embed a DLL within my executable.  I didn’t want to deploy multiple DLL’s – I was trying to keep the number of dependencies down, but still centralize the common routines in my logging object.  I found how to embed the logging DLL within my application’s components, and how to call its methods from the application. I wrote about the process on my application’s blog.

I figured out that there may be a case for doing the same with an executable. I have not had a reason to do it at Passport, but I am writing about it anyway…and looking for an opportunity to use it

To recap, the point of this exercise is to embed an executable within our application, and then make a call to it while our application is running.  To set this up, we need to pull the EXE into our application and then mark it to be placed in the resource list.  Once there we can reference it using reflection, and then use it.  In the case of the DLL, we created an instance of it, and then called its methods. For an EXE it is a little simpler. We just get the EXE from the application’s resource store, stream it to a file, and the start it using “Process.Start”.

This article uses the following demo application as reference for explaining how to do this: [Download the DEMO here]

To add the EXE to the resource store of your application, do the following:
Right-click on your application in the solution explorer, and select “add existing”.

Note: Do NOT use the Add reference option.

Navigate to, and select, the EXE you want to embed.
Now, Select the EXE, and open the properties window. The first property is “Build Action”. Change the option to be “Embed Resource”.

When you compile the project, the exe will be drawn in to your executable and will be available as a resource.

Now, to use the embedded EXE, you need to:

- pull the referenced EXE into a stream from the resource list

- read the stream into a buffer

- write it to a file

- start it as you would for any executable.

You can even pass in command line parameters just as you would for any other EXE

To make this easier, I created a helper class (EmbeddedAssemblyHelper.vb) to take care of reading the resources and working with them.  There is a shared function “LoadExecutable” which reads the EXE from the resource stream, saves it to a unique file and then returns the file name. The calling application can then start the executable by calling Process.Start.

For simplicity, I have the method accepting the EXE’s name. It might be desirable to have the “LoadExecutable” method discover the EXE’s name.

The downside to this is that is it much slower than simply executing the EXE.  So, there needs to be a very good reason to embed your EXE within another (besides the coolness factor, that is )  I can see a use for it in simplifying distribution.  It would also make dealing with obfuscation much easier.

I love to hear of any real world uses for this technique.  Email me at grant.porteous@passporthealth.com

Thanks for reading,

Grant

Back in the pre-dawn of time (around 1999/2000), in the time of COM, we had an in-house utility DLL that was used to determine if a user had permission to a particular resource within our application.  It is literally 15 lines of code and is used in many other objects.

The DLL was named “security.dll”.  To repeat, it was a COM DLL.

Occasionally, nay, randomly, our applications started crashing in horrible ways.  Do you see the problem?  We didn’t for a long time.

It turns out that Windows NT had a “security.dll” for “Security Support Provider Interface” functions.

When we registered our “security.dll” lots of interesting things happened – especially when trying to access network resources…like the database, for example – which we do a million or more times a day. 

That was the birth of our Naming Convention Standards Document which later evolved into our Coding Standards Document.  We agreed to use Hungarian Notation.  Trivia: I noticed in that linked article that it’s called “Hungarian” because of the way Hungarians use the reversed form of their names (Last Name, First Name, as in Data Type, Descriptive Name)).

All applications are now named with a “PHC_” prefix.  “security.dll” became “PHC_Security.dll”.  Our variable declarations start with a 3-letter data type prefix.  (strPayerName, blnFinished, intClaimCounter etc).  We do not, however, prefix our method names – not quite sure how it came about that we skipped that part of naming convention “theory”.  Perhaps it was an intuitive agreement with Linus Torvalds:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged – the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

(lol!)

Perhaps, if Microsoft had used the convention of prefix naming their objects, they’d have named their DLL “MS_Security.dll” and we’d not have wasted a week crashing our production servers with a poorly named 15 lines of code.

Now that we are on .Net and the VS IDE does so much to make code readable, it could be argued that it is no longer required to use a specific naming convention.

I argue otherwise.  Having this standard (and others like it) in place encourages (enforces?) a kind of coding discipline, in my opinion.

I am very particular about code readability.  I do care about code that works – don’t get me wrong – but I care deeply about code that looks good.  I am obsessive about how the code looks. It must be pretty!  My eyes bleed when I see this type of code:


<snip>....some while loop code up here
If i = Len(name) Then
If Quit = False Then
If ins + 1 = 200 Then
previous = i
i = Len(name) + 1
Else
GetParms = ""
Exit Function
End If
End If
End If
</snip>....end of the while loop down here somewhere

….somewhere, someone just killed a kitten because I posted that snippet.

The impression badly named and badly formatted code leaves me with is: “this developer has a cluttered mind, and is most likely writing code that breaks very easily.  I am with illogical”. 

This prejudice I have proves itself often enough to reinforce it for me (prejudices are funny that way).  Sloppy code would kill our company with the number of times we refactor production code.

We have retained the tradition of specific naming standards in our .Net code.  As we have grown, and have more developers interacting with each others code, the coding standards that were created from the “security.dll” incident has made a definite improvement in our productivity and in the quality of our product.

Read:  A Taxonomy for “Bad Code Smells”

A little about the development environment at Passporthealth:

The company was founded in 1996 – around the time Mr Gore invented the internet.  I believe I was the 9th developer hired, 7 of us still work here.  It started off as a Microsoft, VB6 shop and has remained on the MS, VB path ever since.

Our users connect to us via our website portal to verify patient data and eligibility for services via a number of our products.  We have products that allow single web based interactions, file batch transactions and EDI socket transactions.  Each of these various types of requests usually result in a connection to a 3rd party to lookup or validate various patient information.  We store, analyze and embellish all this data and serve it back to the requesting users.  Sometimes this is an immediate response via the web browser, and sometimes we script or post the data back directly into the client’s HIS systems.

Last year we processed over a 100 million such transactions.  This transaction volume and workflow creates tremendous architectural challenges for our IT team.  We have vast quantities of data that are written to, searched, and re-written to.  Our array of products crosses over from data-warehouse driven type applicaitons, to real time transaction processing functions. 

We have tight relationships with our clients where we are intimately involved in their daily work flow;  they depend on our availability and performance to effectively do their jobs.  Delays, or errors caused by our vendors and partners, are our errors.  We’ve successfully (imo) coded and architected around these challenges and this has allowed us to become a dependable supplier of information and utiltiy to our clients.

We have some extremely bright, dedicated and devoted developers.  We solve these complex problems in unique and interesting ways every day, and our company rewards us with a great environment to work in.

My plan for this blog is to talk about those challenges and explore some of the specific solutions.  Perhaps you’d like to read and comment…