Comments by MikeD 2 (Top 5 by date)

lol, possible but fortunately not the case

logged in as an administrator and run cmd "as an administrator"

Not machine specific as I have tried this on a number of windows 8 PCs

I think the version of Outlook is irrelevant as is outlook itself as my problem is that I haven't been able to register this dll in Windows 8 (or 8.1)

To support this viewpoint the dll works with Outlook 2013 in Windows 7

I will try moving it to .net although I was hoping to find some way of identifying what the error message means and how to debug it as I have a feeling it is a permissions issue in the registry. Which is supported that a PC running windows 7 where the dll was already registered continued to allow the dll to work after the PC was in place upgraded to windows 8. This worked until I un-registered the dll as a test and now cannot register it again

Thanks Mike, unfortunately this didn't make any difference

I don't know if it makes a difference but the dll was produced from vb6. I didn't say initially as it seems to me that a dll format should be consistent and either 32 bit or 64 bit but the source program shouldn't matter. But just in case...

Thank you for the response

I am reluctant to use an activex solution as I don't want to build something into a product if I haven't seen all the source

I have seen the oode that you linked but was looking for hmacsha1 rather than sha1 also the key handling appears to be very specific in size whereas the solution I need has to handle a 17 character non hex key and a variable length string message

I am somewhat confident of the sha1 aspect of the code I am using but trying to hmac this doesn't produce the expected results

I appreciate my original question probably looked a bit lazy but there is a reasonable amount of code in my test project and I thought it would be too much to put in a code block. This is my first question so not entirely sure of the right way to do things