Once unblocked, it will not throw up that frightening first message box.
Let's hope this annoying issue will be addressed soon.
Thursday, June 23, 2011
Using PasswordSafe in Windows 7
I am surprise to see the latest version (ver 3.25.0.4042) still does not have the embedded manifest file to tell the Windows 7 the execution level required. When you invoke the pwsafe.exe, it triggers the UAC's attention resulting in this message box:
Not nice. You can prevent this by unblocking it. To do this, you right mouse click on the program in Windows Explorer and then select the properties. On the general tab in the properties dialog box, you should see the 'Unblock" button as circled below:
Once unblocked, it will not throw up that frightening first message box.
Let's hope this annoying issue will be addressed soon.
Once unblocked, it will not throw up that frightening first message box.
Let's hope this annoying issue will be addressed soon.
Tuesday, June 14, 2011
Safe way to close down a ClientBase<T> object
Recently a good friend of drew my attention to a situation I consider a bad disposable object implement and pointed me kindly to an MSDN article offering some words of advice and work around. This saved me considerable research effort. I will address the bad disposable object implementation later.
The problem is that when using the using statement to dispose a ClientBase(of T) object, the base class of WCF proxy stub, you can run into a problem where leaving the using scope the exception thrown in the Dispose() can mask out application exception that causes the execution to leave the scope in the first place. This denies the client the knowledge of the application exception.
The MSDN article explains this phenomenon very clearly and provides an excellent recommendation to handle this problem. The recommended work around places higher value on the application exception as compared to the one that is likely to happen when the Dispose(), or rather Close(), is called. The recommendation uses a multi-level of catches and then use either ClientBase(of T).Close() or its no-throw equivalent ClientBase(of T).Abort() strategically.
While the work around code presented in the article is written in a style that shows clearly how to tackle the problem, it is rather clumsy to use in real life. It expects too much from developer to know when to called Abort() and when to call Close(). Furthermore, it changes the shape of the code drastically to a somewhat awkward and unfamiliar form. It therefore leaves room for improvement and a simple class designed to meet the following objectives is described below:
This SomeHelper class must meet the above objectives.
Recognizing the issue at hand is how to handle the System.ServiceModel.ICommunicationObject, one of the interfaces implemented by ClientBase(of T), I construct the following disposable generic class called SafeCommunicationDisposal.
The fundamental principle is to tell SafeCommunicationDisposal what to use to close down the ICommunicationObject when execution leaves the using scope.
If it leaves by normal means, the SafeCommunicationDisposal.SafeToClose() sets a flag to tell the SafeCommunicationDisposal.Dispose() to use ICommunicationObject.Close(). If Close() throws an exception, it is then passed to the user.
If it leaves as a result of an application exception, SafeCommunicationDisposal.SafeToClose() will not be executed and SafeCommunicationDisposal.Dispose() will use ICommunicationObject.Abort(), a no-throw method to shut down the communication gracefully. This does not mask out the application exception.
If a developer forgets to call SafeCommunicationDisposal.SafeToClose(), the SafeCommunicationDisposal.Dispose() takes a more defensive route of calling the ICommunicationObject.Abort().
I believe this class can help to make the code more readable, maintainable and using a familiar using pattern to correct the naive usage that minimize code change.
The moral of this story is that if you are designing a disposable object, it is wise to heed the following advice "Avoid throwing an exception from within Dispose except under critical situations where the containing process has been corrupted (leaks, inconsistent shared state, etc.).". This is a well known no-no in unmanaged C++.
The problem is that when using the using statement to dispose a ClientBase(of T) object, the base class of WCF proxy stub, you can run into a problem where leaving the using scope the exception thrown in the Dispose() can mask out application exception that causes the execution to leave the scope in the first place. This denies the client the knowledge of the application exception.
The MSDN article explains this phenomenon very clearly and provides an excellent recommendation to handle this problem. The recommended work around places higher value on the application exception as compared to the one that is likely to happen when the Dispose(), or rather Close(), is called. The recommendation uses a multi-level of catches and then use either ClientBase(of T).Close() or its no-throw equivalent ClientBase(of T).Abort() strategically.
While the work around code presented in the article is written in a style that shows clearly how to tackle the problem, it is rather clumsy to use in real life. It expects too much from developer to know when to called Abort() and when to call Close(). Furthermore, it changes the shape of the code drastically to a somewhat awkward and unfamiliar form. It therefore leaves room for improvement and a simple class designed to meet the following objectives is described below:
- Perform automatic closure of the ICommunicationObject using the same elegant form of the using statement.
- Prevent the application exception, the one that is thrown inside the using statement scope, from being masked and passing it to the client unhindered.
- If no application exception, it allows exception that can be generated during the disposable of the ICommunicationObject to pass to the client.
public void GetSomeData( .... ) {
using( SomeHelper helper = new SomeHelper( new CalculatorClient() ) ) {
GetData( helper.Instance() );
}
This SomeHelper class must meet the above objectives.
Recognizing the issue at hand is how to handle the System.ServiceModel.ICommunicationObject, one of the interfaces implemented by ClientBase(of T), I construct the following disposable generic class called SafeCommunicationDisposal.
using System;
using System.ServiceModel;
namespace DisposingCommunicationObject
{
public class SafeCommunicationDisposal<T> : IDisposable where T:ICommunicationObject
{
public T Instance { get; private set; }
public bool IsSafeToClose{ get; private set; }
public void SafeToClose() {
this.IsSafeToClose = true;
}
public SafeCommunicationDisposal (T client) {
this.Instance = client;
}
bool disposed;
public void Dispose() {
Dispose( true );
GC.SuppressFinalize( this );
}
private void Dispose( bool disposing ) {
if( !this.disposed ) {
if( disposing ) {
Close();
}
this.disposed = true;
}
}
private void Close() {
if( IsSafeToClose ) {
Instance.Close();
} else {
Instance.Abort();
}
}
}
}
With this class I can rewrite the naive usage of using the using statment from this:using( CalculatorClient client = new CalculatorClient() ) {
// use client to do work
}
to this form which does not mask out application exception on leaving the using scope and yet closing down the communication object properly: using( SafeCommunicationDisposal<CalculatorClient> d =
new SafeCommunicationDisposal<CalculatorClient> ( new CalculatorClient() ) ) {
CalculatorClient client = d.Instance;
// use the client to do work. If it throws exception
// it will be passed over to the client and not masked by exception
// when client.Close() is executed.
d.SafeToClose(); // This tells SafeCommunicationDisposal to use ICommunicationObject.Close()
}
The fundamental principle is to tell SafeCommunicationDisposal what to use to close down the ICommunicationObject when execution leaves the using scope.
If it leaves by normal means, the SafeCommunicationDisposal.SafeToClose() sets a flag to tell the SafeCommunicationDisposal.Dispose() to use ICommunicationObject.Close(). If Close() throws an exception, it is then passed to the user.
If it leaves as a result of an application exception, SafeCommunicationDisposal.SafeToClose() will not be executed and SafeCommunicationDisposal.Dispose() will use ICommunicationObject.Abort(), a no-throw method to shut down the communication gracefully. This does not mask out the application exception.
If a developer forgets to call SafeCommunicationDisposal.SafeToClose(), the SafeCommunicationDisposal.Dispose() takes a more defensive route of calling the ICommunicationObject.Abort().
I believe this class can help to make the code more readable, maintainable and using a familiar using pattern to correct the naive usage that minimize code change.
The moral of this story is that if you are designing a disposable object, it is wise to heed the following advice "Avoid throwing an exception from within Dispose except under critical situations where the containing process has been corrupted (leaks, inconsistent shared state, etc.).". This is a well known no-no in unmanaged C++.
Thursday, June 2, 2011
Caveat in using Matlab DLL in ASP.Net
I was crafting another WCF Service using basicHttpBinding that used a Matlab NE Builder generated DLL and was keep getting System.TypeLoadException on the class' constructor. This problem was reported but there was no conclusive explanation other than ASP.Net page time out being set too short. But setting that to a long value did not help and certainly did not help me.
My unit test using the DLL directly proved that the DLL was working perfectly and hence it must be environmental. Not the person easily defeated by this kind of issue, I took this up as just another challenge. There must be an explanation.
Being certain that it was environmental, I began to investigate the ASP.Net runtime infrastructure. I know when the Matlab DLL, called a deployment DLL for all the right reasons, was first used, Matlab runtime will expand the embedded scripts, albeit compiled, into a runtime folder structure under the matlab_mcr folder. This folder structure replicates the same directory structure from the root directory when the deployment DLL was built. matlab_mcr is the folder created at a nominated directory.
So if when you build your deployment DLL in say
Matlab runtime will try to create a structure like this:
where [TempDirBase] is the base directory where your run time is going to use. If it is the %Temp%, then in XP it is
If you are like me using very verbose and easy to remember project name organized in a meaningful directory structure and using long matlab function names, the path that Matlab replicates at run time can easily approach the maximum limit of a path name.
In fact the cause of the TypeLoadException by the matlab class was exactly what I encountered when I was using NUnit to unit test code that used a deployment DLL. In NUnit I simply changed the shadow copy directory.
In the ASP.Net situation, the length of the default ASP.Net temporary directory path coupled with my build location caused the operating system to fail to recreate the matlab run time structure because the path length exceeded the maximum permissible length.
Armed with prior experience and the ability to change the ASP.Net default temporary file directory to a different location, I used a 2-prong attack to ensure that matlab's silly recreation of the directory structure will not bother me anymore.
Here is my technique to fix this problem:
1) Build the deployment DLL in a extremely cryptic and shorten path.
Build the deployment DLL in a very cryptic and extremely short path like this c:\0\1 or c:\01. I choose this pattern because I am going to have several of these deployment DLLs and so each one can grab a different number as directory name. Since this is only for run time and it is totally meaningless human, they can be very cryptic. The aim is to make it as short and as flat as one can get and.spare no mercy to Matlab.
You can even use these numbers as your extra version identifier.
This recommendation does not mean that you need to store your project that way. You should store them in as meaningful directory as you can for easy of maintenance and team spirit. By default action, when Matlab replicates this at runtime, it discloses your project organization and if you store your project in the profile area, Matlab can disclose who you are. By using a cryptic and short build path, you prevent Matlab from disclosing such information.
Since I always build these deployment DLLs with a batch file for good technical reasons, it is only a matter of adding extra batch commands to create the build directory described above, and to copy all the .m, .prj, .cs, etc. to the build directory and kick the build from that build directory.
When the build is finished, you copy the output files back to a generated output directory in my solution. The batch file can include commands to remove the build directory.
2) As an extra measure to combat this Matlab bloated directory problem, you change the ASP.Net temporary file directory, which is conveniently applicable per application using the web.config.
This can be achieved by specifying your temporary directory to a very short path name in the tempDirectory attribute of the <compilation> element.
Arm with these and a very long "ASP Script timeout" for your application, changed via the IIS console, you should have no trouble with using Matlab deployment DLL in IIS.
My unit test using the DLL directly proved that the DLL was working perfectly and hence it must be environmental. Not the person easily defeated by this kind of issue, I took this up as just another challenge. There must be an explanation.
Being certain that it was environmental, I began to investigate the ASP.Net runtime infrastructure. I know when the Matlab DLL, called a deployment DLL for all the right reasons, was first used, Matlab runtime will expand the embedded scripts, albeit compiled, into a runtime folder structure under the matlab_mcr folder. This folder structure replicates the same directory structure from the root directory when the deployment DLL was built. matlab_mcr is the folder created at a nominated directory.
So if when you build your deployment DLL in say
"C:\Documents and Settings\John\My Documents\My Matlab Project"
Matlab runtime will try to create a structure like this:
[TempDirBase]\matlab_mcr\Documents and Settings\John\My Documents\My Matlab Project
where [TempDirBase] is the base directory where your run time is going to use. If it is the %Temp%, then in XP it is
"C:\Documents and Settings\John\Local Settings\Temp"
If you are like me using very verbose and easy to remember project name organized in a meaningful directory structure and using long matlab function names, the path that Matlab replicates at run time can easily approach the maximum limit of a path name.
In fact the cause of the TypeLoadException by the matlab class was exactly what I encountered when I was using NUnit to unit test code that used a deployment DLL. In NUnit I simply changed the shadow copy directory.
In the ASP.Net situation, the length of the default ASP.Net temporary directory path coupled with my build location caused the operating system to fail to recreate the matlab run time structure because the path length exceeded the maximum permissible length.
Armed with prior experience and the ability to change the ASP.Net default temporary file directory to a different location, I used a 2-prong attack to ensure that matlab's silly recreation of the directory structure will not bother me anymore.
Here is my technique to fix this problem:
1) Build the deployment DLL in a extremely cryptic and shorten path.
Build the deployment DLL in a very cryptic and extremely short path like this c:\0\1 or c:\01. I choose this pattern because I am going to have several of these deployment DLLs and so each one can grab a different number as directory name. Since this is only for run time and it is totally meaningless human, they can be very cryptic. The aim is to make it as short and as flat as one can get and.spare no mercy to Matlab.
You can even use these numbers as your extra version identifier.
This recommendation does not mean that you need to store your project that way. You should store them in as meaningful directory as you can for easy of maintenance and team spirit. By default action, when Matlab replicates this at runtime, it discloses your project organization and if you store your project in the profile area, Matlab can disclose who you are. By using a cryptic and short build path, you prevent Matlab from disclosing such information.
Since I always build these deployment DLLs with a batch file for good technical reasons, it is only a matter of adding extra batch commands to create the build directory described above, and to copy all the .m, .prj, .cs, etc. to the build directory and kick the build from that build directory.
When the build is finished, you copy the output files back to a generated output directory in my solution. The batch file can include commands to remove the build directory.
2) As an extra measure to combat this Matlab bloated directory problem, you change the ASP.Net temporary file directory, which is conveniently applicable per application using the web.config.
This can be achieved by specifying your temporary directory to a very short path name in the tempDirectory attribute of the <compilation> element.
Arm with these and a very long "ASP Script timeout" for your application, changed via the IIS console, you should have no trouble with using Matlab deployment DLL in IIS.
Thursday, May 26, 2011
Apple users, welcome to the real world!
If you have not be told Apple has virus, you should read this excellent piece of report on "Mac Defender" malware. As a realist, I have always laughed when Apple users naively believing the sales hype that it does not virus!
I have been following this Mac Defender for a long time, way before the popular media outlets picked up the story. When I first heard of this, I realized that apple users' age of innocence had just been shattered. My warning to my friends and view on the vulnerability of these unrealistically complacent apple users would be like pack of drunken sheep to the wolf. Surprisingly this same sentiment is echoed by Molly Wood in CNet. As a developer, software bounds to have vulnerability as it is crafted by human. Besides, Apple OS is just a Unix and Unix/Linux is always known to be malware/virus.
I believe it will become a lot worse before it gets some form of relief because these attackers have sharpened its modi operandi in the Windows world and that Windows users are conditioned to become more alert about Virus/Trojan/Malware. To these attackers, Apple users are trusting lot!
I am not surprised to learn of the recommended "unhelpful" customer service directive of Apple as reported. Molly has outlined several notable exemplars of Apple's unhelpfulness. The "silence-then-solution pattern" will definitely put their users at great risk through Apple's generosity of giving attackers a wide windows of attack opportunity. Does Apple care? I doubt it. The old "Poison DNS attack" and Apple's slowness in addressing this is just another shiny example of a company cares more about a facade than what's behind and its users well beings.
I have been following this Mac Defender for a long time, way before the popular media outlets picked up the story. When I first heard of this, I realized that apple users' age of innocence had just been shattered. My warning to my friends and view on the vulnerability of these unrealistically complacent apple users would be like pack of drunken sheep to the wolf. Surprisingly this same sentiment is echoed by Molly Wood in CNet. As a developer, software bounds to have vulnerability as it is crafted by human. Besides, Apple OS is just a Unix and Unix/Linux is always known to be malware/virus.
I believe it will become a lot worse before it gets some form of relief because these attackers have sharpened its modi operandi in the Windows world and that Windows users are conditioned to become more alert about Virus/Trojan/Malware. To these attackers, Apple users are trusting lot!
I am not surprised to learn of the recommended "unhelpful" customer service directive of Apple as reported. Molly has outlined several notable exemplars of Apple's unhelpfulness. The "silence-then-solution pattern" will definitely put their users at great risk through Apple's generosity of giving attackers a wide windows of attack opportunity. Does Apple care? I doubt it. The old "Poison DNS attack" and Apple's slowness in addressing this is just another shiny example of a company cares more about a facade than what's behind and its users well beings.
Monday, May 16, 2011
Complete build process of Matlab component for .Net with meaningful version number
The previous post describes a recipe for injecting meaningful version number into NE Builder produced .Net assembly.
The normal NE Builder generated assembly using non-embedded CTF archive requires the use of a /linkres option to describe in its manifest an external linkage to a CTF file. Unfortunately, this option is not available to Visual Studio C# project and as a result, it is not possible to create a class library project in Visual Studio to automate this process; batch process is still required.
Incidentally, some one in the forum was puzzled by the automatic copying of the CTF file when one referenced a NE Builder generated assembly. This action is caused by the use of /linkres option.
In view of the need to use a batch file or command line operation to build the .Net assembly, it is therefore advantage to automate all the build steps without the need to invoke the Matlab IDE to generate the external CTF archive, the C# and companion files. Below are the steps to construct this batch file:
1. Create a command to invoke the Matlab component compiler (mcc.exe) to generate the CTF archive, the C# and companion files using the -F switch with your Matlab prj file. To see this switch usage, invoke MCC -? on a command prompt.
This switch takes all the setting from the PRJ file and is a convenient way to centralize all the specifications in one place that is also available to Matlab IDE, which is a convenient visual tool to set those specifications.
2. Execute the CSC.EXE, the C# compiler, with the response file constructed as described in the previous post.
This batch program generates all the files afresh without the need to rely on part IDE build and part command line build to complete the process; this technique ensures all files are in sync and that it can be incorporated into any automatic build process.
The normal NE Builder generated assembly using non-embedded CTF archive requires the use of a /linkres option to describe in its manifest an external linkage to a CTF file. Unfortunately, this option is not available to Visual Studio C# project and as a result, it is not possible to create a class library project in Visual Studio to automate this process; batch process is still required.
Incidentally, some one in the forum was puzzled by the automatic copying of the CTF file when one referenced a NE Builder generated assembly. This action is caused by the use of /linkres option.
In view of the need to use a batch file or command line operation to build the .Net assembly, it is therefore advantage to automate all the build steps without the need to invoke the Matlab IDE to generate the external CTF archive, the C# and companion files. Below are the steps to construct this batch file:
1. Create a command to invoke the Matlab component compiler (mcc.exe) to generate the CTF archive, the C# and companion files using the -F switch with your Matlab prj file. To see this switch usage, invoke MCC -? on a command prompt.
This switch takes all the setting from the PRJ file and is a convenient way to centralize all the specifications in one place that is also available to Matlab IDE, which is a convenient visual tool to set those specifications.
2. Execute the CSC.EXE, the C# compiler, with the response file constructed as described in the previous post.
This batch program generates all the files afresh without the need to rely on part IDE build and part command line build to complete the process; this technique ensures all files are in sync and that it can be incorporated into any automatic build process.
Wednesday, May 11, 2011
Caveat in NUnit testing Matlab NE Builder produced assembly
Matlab NE Builder produced assembly when loaded needs to extract the compiled scripts into a cache area which is normally in the executable directory.
When such an assembly is being tested in NUnit, with Shadow Copying enabled (the default setting), can generate a file path that exceeds the maximum length of file path name of Windows.
When this happens, it can generate an exception saying that it cannot create an instance of MCR. Check the Text output tab of NUnit console for any message saying something like this:
If you still want to use Shadow Copying support in NUnit, go to NUnit's console's settings dialog and specify a short directory as a Shadow Copy Cache, which is usually your "%Temp%\nunit20\ShadowCopyCache". Alternately turn off the Shadow Copy can help to alleviate this problem.
When such an assembly is being tested in NUnit, with Shadow Copying enabled (the default setting), can generate a file path that exceeds the maximum length of file path name of Windows.
When this happens, it can generate an exception saying that it cannot create an instance of MCR. Check the Text output tab of NUnit console for any message saying something like this:
Failed to removeWhere
Verify file ownership and access permissions.
If you still want to use Shadow Copying support in NUnit, go to NUnit's console's settings dialog and specify a short directory as a Shadow Copy Cache, which is usually your "%Temp%\nunit20\ShadowCopyCache". Alternately turn off the Shadow Copy can help to alleviate this problem.
Recipe to add assembly version to Matlab NE Builder produced assembly
Matlab NE Builder, once called .Net Builder, is a tool from Matlab to package the Matlab script (the .m files) into a .Net assembly making the functions specified in Matlab available to .Net application.
This tool unfortunately provides token .Net infrastructure support. It can produce a strongly named assembly but it does not have facility to allow user to specify the assembly version data, a vital piece of information to support strict version binding policy.
Every assembly produced by NE Builder, regardless strongly name or not, has the version 0.0.0.0. As a result it is not very useful. According to Matlab forum, Matlab does not have any way to deal with this issue. This blog post provides a recipe of allowing user to add assembly version or any other pieces of information to the NE Builder produced assembly. It does not use any undocumented or hack to produce the result; it simply uses the same standard .Net build specifications the NE Builder Deployment tool uses.
This recipe then allows one to produce a versionable strong name .Net assembly that carries the Matlab script.
This tool unfortunately provides token .Net infrastructure support. It can produce a strongly named assembly but it does not have facility to allow user to specify the assembly version data, a vital piece of information to support strict version binding policy.
Every assembly produced by NE Builder, regardless strongly name or not, has the version 0.0.0.0. As a result it is not very useful. According to Matlab forum, Matlab does not have any way to deal with this issue. This blog post provides a recipe of allowing user to add assembly version or any other pieces of information to the NE Builder produced assembly. It does not use any undocumented or hack to produce the result; it simply uses the same standard .Net build specifications the NE Builder Deployment tool uses.
- From the Deployment tool (read NE Builder) build the assembly and making sure that you clear the "Embedded the CTF Archive". This is because when you use embedded CTF archive, the builder deletes the CTF file after building the assembly. We need this file in the subsequent steps and hence not embedding lets us access this file. Furthermore, it is easier if you make the source and output directory the same.
- Save the build steps to a build log and open it with a text editor.
- Look out for the line containing the CSC.exe as we will use that to produce the response file for the C# compiler.
- Copy the text after CSC.exe into a text file. You can insert line break to make it more readable.
- Add AssemblyInfo.cs to the response file. This file contains the assembly information you wish to include into the assembly.
- Save the text file into a file with customary .rsp extension into the same directory as the source.
- Create the AssemblyInfo.cs file if not exist and specify your assembly version and other information.
- Run the CSC with this response file to produce your assembly which will contain the required assembly version.
This recipe then allows one to produce a versionable strong name .Net assembly that carries the Matlab script.
Subscribe to:
Posts (Atom)
