PlausiblyDamp

That looks like it is at least running your application till it hits a line of code where you are trying to use the Outlook component (it is crashing in your Form_Load rather than earlier in the application). Try putting a Try ... Catch block around the code you are using to instantiate the outlook component - if an exception is raised then outlook probably isn't installed.

In the line IAsyncResult result = aconv.BeginInvoke(fullpath, outfilename, out sErrMsg, true, aconvcallback, null); you are passing null as the last parameter - whatever you pass in here is what you get with the IAsyncResult.AsyncState property.

Is it crashing before you are using them in code though? Will the application run ok until it actually attempts to use the Outlook COM objects?

Does your application crash even before the Outlook COM Classes are referenced or is it just failing to create the objects? If the object isn't registered then it should throw a trappable exception when it fails to create a valid instance - could you not simply catch this and notify the user?

Is this a web or windows application? If a web application are the 2 code files placed in the App_Code folder?

Does the error message give any further details?

There is no reason at all why you can't use a stored proc as part of a SqlTransaction. The only thing you might need to be careful about is if the stored proc itself also begins it's own transactions.

http://www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx is probably the easiest option - it's a free zip library that provides methods for things like extracting files / listing files in a zip etc.

Re: CreateObject and late binding The code I posted earlier is definately all you need to create an instance of a COM object (assuming it is referenced by your project), this will also allow you to use early binding which should be better for performance. If you step through the code in a debugger are you getting valid instances of the objects created? If so then you shouldn't need to use either Activator.CreateInstance or Server.CreateObject to instantiate the objects.

It might be easiest to use your application as the windows shell clicky has a brief run down of what you need to do (basically change a registry key to point to your application).

Re: CreateObject and late binding Still not entirely sure what the actual error you're having is; is it failing to create the objects? The objects failing to execute correctly? Some other problem?

As a very basic tool you can get MS's Application Center Test (it ships with some version of VS anyway) - it's basic but does allow you to record a user using your site and then replay it back (as multiple simultaneous users as well) and will allow you to record various statistics about the site's behaviour. Also windows itself include Performance Monitor which is also a good tool for identifying potential problems. Classic ASP might be causing some problems due to it's interpreted rather than compiled nature - but unless the people who are saying there are performance issues can back this up with some evidence it would appear you are wasting your time...

Re: CreateObject and late binding If you add a reference to the dll itself could you not just do something like Loader mglLdr = new MagellanSolo.Loader; MagellanSolo mglObj = (MagellanSolo)mglLdr.MagellanSolo;

You could use the FindControl method of the page to locate the correct control Don't have VS handy but the code would be something like dim l as Literal l = FindControl("Literal" & index.ToString()) l.Text = "New Value"

You could just use something simple like an ArrayList or HashTable if you are using .Net 1 / 1.1. If you are using .Net then something like a generic List or Dictionary may be easier to use.

Re: CreateObject and late binding Could you post a sample of the code you are using that isn't working? Also when you say 'doesn't seem to work' is it failing in any particular way? Late binding will affect performance (just how much really depends on several factors) as you are doing a lot of work at runtime (id lookups, interface lookups, method lookups etc.) that can be done by the compiler if you are early binding.

Without actually checking I would guess it is a wrapper around the SHFileOperation API call - in fact you can get the relevant C# imports at clicky

Vista has a major version of 6 and a minor version of 0, on the current release it is shown as 6.0.6000.0 - realistically you would only require the 6.0 part of the version unless you were after a specific service pack or similar.

Could you give a little more detail about how you are generating the SQL Insert command and where the information is coming from? If you are just concatenating strings then you will get potential issues if the SQL / Application have differernt regional settings and date time formats. If you could use either a stored procedure or a parameterised query then this issue would probably go away.

Delegates (at their simplest anyway) are really just typesafe function pointers, therefore under C / C++ there isn't a direct replacement for the delegate keyword as you can just use a normal function pointer.

I know you need SP1 and a patch for VS 2005 to run under Vista but I've not come across anything that mentions 2003 being supported under vista though.

You can always get the command line passed into your application through Environment.CommandLine To launch another process and pass in a command line use System.Diagnostics.Process.Start("secret.exe", "/myParameter")

You don't need to apply the attributes to your own function - just paste them direct within your class and leave your original function as it was. i.e. private Class Test Class _ Private Shared Function FindWindow(ByVal lpClassName As String, ByVal lpWindowName As String) As IntPtr End Function _ Private Shared Function FindWindowByClass(ByVal lpClassName As String, ByVal zero As IntPtr) As IntPtr End Function _ Private Shared Function FindWindowByCaption(ByVal zero As IntPtr, ByVal lpWindowName As String) As IntPtr End Function Private Sub TestMethod Dim hhwnd As Integer hhwnd = FindWindow(vbNullString, "AnotherApp") If hhwnd <> 0 Then MessageBox.Show ( "Another app is running.") End 'Exiting your application this way is not normally a good thing either... End If End Sub End Class

It's probably down to your declaration of FindWindow - various datatypes etc. have changed since VB6. Try replacing your declaration with the following _ Private Shared Function FindWindow(ByVal lpClassName As String, ByVal lpWindowName As String) As IntPtr End Function _ Private Shared Function FindWindowByClass(ByVal lpClassName As String, ByVal zero As IntPtr) As IntPtr End Function _ Private Shared Function FindWindowByCaption(ByVal zero As IntPtr, ByVal lpWindowName As String) As IntPtr End Function

You would still use the designer for everything just the same - the difference is in how you create a run-time instance of the form. http://www.xtremedotnettalk.com/showthread.php?t=83092 goes into more detail about using forms under .Net including how to create an instance and also passing information back and forth between multiple forms.