Goto 100 - Development with Visual Basic : DevCenter

ClickOnce and Security

Eric Nelson — Mon, 15 Jun 2009 18:27:00 GMT

ClickOnce deployment is another area where Code Access Security needs to be kept in mind. ClickOnce deployments will often be used to deploy Visual Basic .NET (or hybrid Interop Toolkit) applications from a website or network file share. In these cases, the applications don't get the standard Full Trust permissions in CAS. Instead they get the more limited Internet Zone permissions. As a developer, you will need to ensure that your application can run successfully with this permission set. Visual Studio can help out here, so rather than having to mess around with your security policy while you're debugging, Visual Studio can set up a debugging session with the required permissions (look on the Security page of your project properties to see how to configure this behaviour).

If the set of permissions granted to the Internet Zone aren't sufficient then you have two options:

Ask for the additional permissions in the ClickOnce deployment manifest, and rely on the user accepting the elevated permission request during the install.
Ask your administrator to configure the standard CAS policy on end user machines to permit elevated permission requests from specific publishers. You then use Authenticode to sign the deployment manifest, using the permitted publisher details.

Option 2 is obviously to be preferred, but needs a bit more work to get set up.

Introducing code obfuscation

Eric Nelson — Fri, 12 Jun 2009 18:24:00 GMT

If you recall from an earlier post, I said that the main reason for signing an assembly and giving it a strong name was to prevent it being tampered with. For example, many of the assemblies that make up the .NET framework itself are strong-named assemblies that sit in the GAC. If I disassembled one of these, messed around with the IL code, and then reassembled it, I'd have to sign it with my signature. Running any existing applications that used the assembly I'd changed would now fail, because the signature had changed. That's all great in that it stops anyone tampering with existing, deployed assemblies.

What may still be a concern is that the IL code is still legible, so that anyone can see how your code works and what it does (provided they spend a bit of time getting familiar with IL code). This raises the issues of intellectual copyright and opens the potential for security breaches as unscrupulous developers can easily look for weaknesses in your application.

Enter code obfuscation (Dotfuscator on Visual Studio's Tools menu). This utility renders the contents of your assemblies (the IL code), incomprehensible to human readers, but leaving it so that it can still be run by the CLR. This is done by renaming everything in sight, variables, classes, methods etc with meaningless or duplicate names. Obfuscation is an excellent demonstration of how useful good names are to understanding code!

Code Access Security in action – calling Unmanaged Code

Eric Nelson — Thu, 11 Jun 2009 18:12:00 GMT

The following is an example of how code access security might affect your code when calling unmanaged code. Unmanaged code is a posh way of saying “It isn’t .NET code, it is the stuff you used to write before .NET” :-)

In VB6 making a call to a Windows API function wasn't affected by any security settings. Potentially in .NET, an administrator might configure a machine's code access security policy to disallow calls to unmanaged code (such as the Windows API), because this is seen as a security risk. That means that code like this, could fail with a SecurityException, when the API function is invoked:

   1:  Module Module1

   2:      Sub Main()

   3:          Win32.MessageBox(0, "Here's a MessageBox", "Platform Invoke Sample", 0)

   4:      End Sub

   5:  End Module

6:

   7:  Public Class Win32

   8:      Declare Auto Function MessageBox Lib "user32.dll" ( _

   9:          ByVal hWnd As Integer, ByVal txt As String, _

  10:          ByVal caption As String, ByVal Type As Integer) _

  11:          As Integer

  12:  End Class

There's nothing you can do to stop the code failing (other than having a word with the administrator), but you can handle things a bit more gracefully. You can check when your app starts up whether you've got all the permissions you want, and then handle the situation before you hit the problem. This can be done with an attribute (declaratively), so the permissions are checked when an assembly is loaded:

<Assembly:SecurityPermissionAttribute(SecurityAction.Demand, Flags := SecurityPermissionFlag.UnmanagedCode)>

You could also perform the check programmatically:

   1:  Try

   2:          Dim sp As New SecurityPermission(SecurityPermissionFlag.UnmanagedCode)

   3:          Console.WriteLine("Demanding SecurityPermissionFlag.UnmanagedCode")

   4:          sp.Demand()

   5:          Console.WriteLine("Demand for SecurityPermissionFlag.UnmanagedCode succeeded.")

   6:          Catch e As Exception

   7:              Console.WriteLine(("Demand for SecurityPermissionFlag.UnmanagedCode failed: " & e.Message))

   8:  End Try

Either way you can test for the permission before you need to use it.

The above checks whether you had the necessary permissions to perform an operation (in this case calling unmanaged code) by using Demand. You can also Assert or Deny a permission.

SecurityAction.Demand
What in fact you're doing here is checking that your assembly has the requested permission, and that any assemblies above you in the call-stack also have that permission.
SecurityAction.Assert
This is a little bit different. You're still checking that your assembly has the requested permission, but you're also saying to the CLR - "Don't bother about checking further up the call stack". In effect, you are taking full responsibility for security. This is usually seen as dangerous behaviour, but there are some circumstances where it's useful.
SecurityAction.Deny
Here you're saying you don't want a permission. Not at first sight much use, because if you don't want to be able to do something, then you won't write any code to try and do it! However, this also switches off the permission for any assemblies that you call (that might have been written by someone else), unless of course they go ahead and do an Assert!

Authenticode and ActiveX controls

Eric Nelson — Wed, 10 Jun 2009 18:02:00 GMT

For VB6 developers, one area where asymmetric keys and digital signatures cropped up was the requirement to sign downloadable ActiveX controls using Authenticode. The idea was to sign the controls using a digital signature so that the origin of the control could always be established.

There are a couple of related concepts in .NET that you'll almost certainly come across sooner or later.

Code Access Security

With ActiveX controls, the default behaviour of Internet Explorer was to prevent their download unless they had a valid signature. In .NET the CLR applies a security policy to all loaded code. The CLR evaluates the code and then decides what that code should and should not be able do. So the CLR will look at a particular assembly, see if it has been signed or where it was loaded from etc., and then decide whether that code is allowed to write to the hard disk or open a network connection and so on. All of these policy rules are stored in configuration files, which in previous versions of the framework you could see and edit using a control panel applet. In .NET 3.5 you're expected to edit this configuration using the command line caspol.exe tool (unless you install the .NET 2.0 SDK).

Strong Names

.NET also uses the concept of strong named assemblies. At first sight this looks similar to signing a component using Authenticode, in that strong named assemblies are digitally signed. However the digital signature is used for very different reasons. First of all, if you want to place an assembly in the Global Assembly Cache (GAC) , it must have a strong name. The digital signature makes your assembly unique, even if someone else has installed an assembly with the same name into the GAC. Secondly, a strong name prevents unauthorised tampering with an assembly. So, although someone can disassemble a strong named assembly using Ildasm, they can't put it back together again with the same signature (unless you've given them your private key!). Any change in the signature is automatically detected by users of the assembly, and the tampering spotted. Strong naming is done with the Sn tool.

Cryptography

Eric Nelson — Tue, 09 Jun 2009 17:58:00 GMT

The second big security area in the .NET framework after Authentication and Authorisation is cryptography. Again, the framework contains a lot of powerful functionality, and again there is an application block that makes it all a bit easier to use.

The classes and namespaces that deal with cryptography cover three key areas:

Symmetric Key Encryption/Decryption
Asymmetric Key Encryption/Decryption (Public Key Cryptography)
Hashing

I don't want to get bogged down in the detail of these three topics (there's plenty of resources elsewhere on the web for that), but just highlight where, in a VB application, these technologies may be useful.

Symmetric Key Cryptography

This kind of encryption algorithm uses a single shared key that can be used to both encrypt and decrypt data. These algorithms are also relatively fast. The fundamental weakness of this approach is that both the encrypting and decrypting parties need to know the same key, and to make sure that no one else has access to the key. The framework includes implementations of a number of well known algorithms of this type such as DES, TripleDES and AES.

Where this is useful in a VB application is where the application wants to store it's own data securely - perhaps as a file, or a section of a configuration file, or a registry key. A couple of useful classes are ProtectedMemory and ProtectedData which look after all the key management issues for you.

Asymmetric Key Cryptography

While these algorithms are slower than the symmetric ones, they don't rely on a single shared key. Instead, they use a pair of keys, on public and one private, where data encrypted with one key can only be decrypted using the other. These algorithms, as well as providing encryption, also form the basis of digital signatures.

This approach is appropriate when exchanging data securely between users or systems. The HTTPS protocol is an example of the use of this approach.

Hashing

You can think of hashing as a one way system, you can encrypt (hash) a piece of data to generate a unique hash code, but you can't work out from a hash code what the original piece of data was. What's the use of this then? An authentication system that verifies passwords is a good example:

You need to check that a user password is correct when they log on - so you need to keep a record of passwords somewhere and the password needs to be transmitted over the network from the client application for checking. This gives you two security loopholes - passwords stored in a database and passwords flying around on the network. If you store a hash of the password in the database, and the client application sends a hashed version of the password for checking we've avoided both problems! We just need to compare hash values to check if the password is correct.

The framework includes implementations of a number of hashing algorithms including SHA and MD5.

Authentication and Authorisation

Eric Nelson — Mon, 08 Jun 2009 17:56:15 GMT

As promised, the first in a series of posts about security relevant to a developer new to .NET (such as a VB6 developer).

These are what most people will immediately think of when security is discussed.

Authentication
This is proving your identity by some means, whether it's knowing your password, having the right swipe card or having your fingerprint checked.
Authorisation
Once a system knows who you are it can apply some rules to decide what you can see or do.

ASP.NET has a huge amount of built-in support for performing authentication and authorisation (a far cry from the situation with ASP) including a full-blown membership system that simplifies creating a web site that requires registration before you can access certain areas of the site.

Authentication and authorisation have tended to be less significant when developing desktop based systems because a) it is a more "controlled" environment and b) the desktop OS can be left to handle these issues for you.

A common scenario where you do need to customise things is where a desktop application needs its own authorisation rules (we can still rely on the OS performing the authentication for us, typically against Active Directory). What we want to do in our application is authorise users using Active Directory (or ADAM) - to minimise the development effort here you should look at the Security Application Block.

What (or who) is ADAM, some of you are asking? Simply put Active Directory Application Mode is a standalone version of Active Directory that you can distribute with your application. Therefore you could have you own authentication database which could also be customised without impacting Active Directory itself.

While I'm on the subject of application blocks, there are a couple of others that relate to security. There's a Cryptography Application Block which I'll talk about in a later post, but for now I wanted to point out the Logging Application Block. This is great if you need to record what's going on in your application for troubleshooting, error reporting, or from the security standpoint, auditing.

Creating log entries from your code is straightforward:

   1:  Dim logEntry As LogEntry = New LogEntry()

   2:  logEntry.EventId = 100

   3:  logEntry.Priority = 2

   4:  logEntry.Message = "User Logon: " + userName

   5:  logEntry.Categories.Add("Audit")

   6:  logEntry.Categories.Add("UI Events")

   7:  Logger.Write(logEntry)

The configuration options of the application block then enable you to control things like where the log messages get written to, and to define filters based on LogEntry fields.

Possible destinations for log messages include: a database, the Windows Event Log, a rolling flat file or an email.

Virtualization and Visual Basic 6.0 applications

Eric Nelson — Sun, 07 Jun 2009 19:33:00 GMT

There may be some circumstances where upgrading a VB6 application is not feasible, for example it may rely on a control that simply does not work in the target operating system. I came across a couple of articles on MSDN that discussed the ways that virtualisation technologies can be applied to this problem. There are three basic approaches:

Run all, or in a virtual machine. Virtual PC, Virtual Server or Hyper-V in Windows Server 2008 are all possibilities.
Use Terminal Services to give end users access to the application.
Use Microsoft Application Virtualization (formally Softgrid) to virtualize a part of the application.

Check out these links:

Aberdeen Group report on Migrating from VB6 to .NET

Eric Nelson — Fri, 05 Jun 2009 18:50:23 GMT

Aberdeen Group have created a new report “Migrating from VB6 to .NET: The challenge of software agility in a volatile economy”

Some bits that stood out for me:

50% will migrate all the applications, 36% will migrate some (86% in total will migrate)
“Best in class” understand the importance of external migration services and tools - 30%+ in each category
14% of organisations said their entire environment is VB6 based.
For those who will NOT migrate to VB.NET:

62% will migrate to C#
10% Other .NET languages
16% Java (tut tut)
12% Other none .NET

Visual Basic 6.0 Migration – due diligence is a good thing

Eric Nelson — Fri, 05 Jun 2009 18:35:53 GMT

Choice in general is a good thing. When faced with moving a Visual Basic 6.0 application to .NET there is plenty of choices to be made. One of those choices is “Which tool should I go with to migrate the code?”.

My advice in general is “Try as many as you can on a representative chunk of your application”.

I spotted over on the VB Migration Partner website a case study which contained an example of just that:

“During the software evaluation phase SIS run a 25K prototype through all the conversion programs. It took 2.5 hours to get a compilable and runnable VB.NET project with VB Migration Partner, and 13 hours with its closest competitor. The reduced effort, the ability to use pragmas and support for the convert-test-fix were the main reasons for choosing Code Architects’ software.”

This was a 650K Lines of Code conversion in just 6 months with a total effort of 18 man-months. Pretty impressive.

P.S. 13/2.5 = 5 times faster, in case you were wondering :-)

Support statement for Visual Basic 6.0 updated for Windows 7

Eric Nelson — Fri, 27 Feb 2009 02:20:41 GMT

I have been asked many times in the last few weeks about Windows 7 and VB6. The support statement has been updated to cover Windows 7 and the news is good.

Windows 7

Since the initial release of this support statement, the Windows 7 operating system has been announced. This document has been updated to clarify Microsoft’s support for VB6 on Windows 7.

VB6 runtime will ship and will be supported in Windows 7 for the lifetime of the OS. Developers can think of the support story for Vista being the same as it is for Windows 7. However there are no plans to include VB6 runtime in future versions of Windows beyond Windows 7.

Results of Visual Basic Survey (UK)

Eric Nelson — Tue, 17 Feb 2009 23:49:30 GMT

In January we created a survey to understand how folks were using Visual Basic 6.0 and Visual Basic .NET in the UK. This survey was sent out to individuals we “suspected” had Visual Basic 6.0 heritage but it was also widely advertised through the UK MSDN Flash to UK developers.

We got plenty of great data and I wanted to share the interesting bits more widely as I think as developers we are always curious about what our peers are up to. Well, I am :-)

Visual Basic Upgrade Wizard vs 3rd Party Migration Tools

Eric Nelson — Thu, 05 Feb 2009 18:45:56 GMT

[If you are UK based, check out www.microsoft.com/uk/vbmigration for more information ]

A question I get asked a lot is “Are 3rd party migration tools really that much better than the free upgrade wizard from Microsoft?”

Lets me be perfectly candid. Whilst I always recommend people should try the free wizard first, it has many shortcomings. Too many IMHO. That said, for some folks it will be perfectly “good enough” to enable a successful migration from VB6 to Visual Basic .NET. However for large, complex VB6 applications you would likely be much better served by a 3rd party tool.

The two main companies in this space have each created a comparison with the Upgrade Wizard which I would definitely recommend you check out.

Code Architects VB Migration Partner

Code Architects have a paper which includes a detailed analysis of the output of their VB Migration Partner compared with the Upgrade Wizard on a number of Open SourceVB6 projects and a look at how well each tool handles compatibility issues as identified by VB Project Analyzer from Aivosto. VB Migration Partner was:

About four times faster
Produced fives times fewer compilation errors in the final .NET code
Able to fully or partially handle 43 of the 49 compatibility issues that are left unresolved by the Upgrade Wizard

Artinsoft Visual Basic Upgrade Companion

Artinsoft have created a detailed whitepaper looking at the many differences between the Wizard and their Visual Basic Upgrade Companion. They are sometimes very big differences – such as how the tool handles 3rd party controls. The paper also includes lots of great code snippets which allow you to directly compare the two tools.

e.g. Error Handling

Original VB6 Source Code:

Public Sub ErrorHandling(arg1 As Integer) 
On Error GoTo ErrorHandler 
    Dim var1 As Integer 
    var1 = 1 / arg1 
    MsgBox var1 
    MsgBox arg1 
    Exit Sub 
ErrorHandler: 
    MsgBox Err.Description, , "Error" 
End Sub

The Upgrade Wizard:

Public Sub ErrorHandling(ByRef arg1 As Short) 
On Error GoTo ErrorHandler 
  Dim var1 As Short 
  var1 = 1 / arg1 
  MsgBox(var1) 
  MsgBox(arg1) 
  Exit Sub 
ErrorHandler:  
  MsgBox(Err.Description,  , "Error") 
End Sub

But the Visual Basic Upgrade Companion uses Try/Catch:

Public Sub ErrorHandling(ByRef arg1 As Integer) 
Try  
  Dim var1 As Integer 
  var1 = 1 / arg1 
  MessageBox.Show(CStr(var1), Application.ProductName) 
  MessageBox.Show(CStr(arg1), Application.ProductName)  
  15 
Catch excep As System.Exception       
  MessageBox.Show(excep.Message, "Error") 
End Try 
End Sub

Do check out the paper, especially the many code samples.

A mocking framework especially designed for Visual Basic .NET

Eric Nelson — Thu, 05 Feb 2009 16:58:52 GMT

I was pleased to see the Typemock folks have delivered a special VB.NET API to use Typemock 5.2 for unit testing. This handles the differences in VB9 vs C# 3.0 around Lambdas (VB9 is restricted to functions where as C# 3.0 can handle statement lambdas – this will be resolved in VB10 aka Visual Basic 2010).

There are three related blog posts which did into this:

I am keen to dig into mocking some more over the next couple of months. Typemock is one such tool but I also need to (minimally) check out Rhino.Mocks and Moq.

You might also want to check out these short screencasts:

Introduction to TypeMock (One of a series)
Mocking with Rhino.Mocks (There are a couple of others also on dimecasts)
Mocking with Moq

New article on extending VB6.0 applications with the Interop Forms Toolkit 2.0

Eric Nelson — Thu, 05 Feb 2009 16:24:32 GMT

I just wanted to swiftly share some useful links if you choose to extend a Visual Basic 6.0 application including a new article I commissioned in the UK – which turned out rather good.

Firstly links to the toolkit download and some of the best existing articles.

The Interop Forms Toolkit 2.0 which you need to download
Interop Forms Toolkit 2.0 Tutorial on Code Project which includes an example of using a WPF control inside a Windows Form as part of a Visual Basic 6.0 application
Using the Toolkit with Visual Foxpro – yep, you can use the toolkit with VFP9
Using C# with the Interop Forms Toolkit and useful blog post from the team

Which leads me to the new article on using the Interop Forms Toolkit. This is a detailed, code heavy look at using the Interop Forms Toolkit which we are getting some great feedback on.

It covers:

Installation and setup
Interop Forms
Interop UserControls
Sharing data between managed and unmanaged code
Debugging
Deployment
And recommendations on using it

Enjoy.

P.S. I must admit I have never liked the name of this kit as it doesn’t really describe what it does - IMHO. I therefore often describe it as

The Add VB.NET Forms and Controls to your VB6 Application Toolkit

However that does it a disservice. It is broader than that. How about

The Add VB.NET or C# Forms and Controls to your VB6 Application Toolkit

Or even more descriptively

The Add VB.NET or C# Forms and Controls to your VB6 or VFP9 Application Toolkit

The Add .NET Forms and Controls written in any .NET language to any COM based Application but it is much easier to use for VB6 and VB.NET Toolkit

Ok I give in, Interop Forms Toolkit 2.0 it is :-)

Secure your Visual Basic 6.0 investment with Microsoft .NET

Eric Nelson — Wed, 28 Jan 2009 23:36:16 GMT

[This is currently a UK only initiative but you will still find a lot of useful information on the new site and I know our partners are happy to engage worldwide]

Over the last couple of months I have been working with Sarah in my group to pull together something which hopefully will help the many companies in the UK who continue to have a significant investment in Visual Basic 6.0 - and we did it with virtually no budget thanks to some great help and encouragement from Artinsoft, Code Architects and Avanade.

Check out what we created if you are based in the United Kingdom and still have Visual Basic 6.0 applications running your company. Some of the highlights:

A great prize draw to win a free copy of a migration tool from Artinsoft or Code Architects (We have several to give away)
Great offers from our partners. How about a entry level great migration tool for just £199 or 25% off a full blown enterprise class tool
An attempt to summarise the five options you can take along with a 10 minute screencast by myself explaining the five options (and you can tell I had a cold when I recorded it!)
Links to the best resources to find out more
And a a brand new detailed article on the Interop Forms Toolkit which enables .NET forms and controls to be easily mixed with Visual Basic 6.0 forms and controls.

P.S. The web page does have one or two “bugs” – but we will get them fixed on the next refresh.