Works on Dev Sys, but No Where Else...

JaedenRuiner

Well-known member
Joined
Aug 13, 2007
Messages
340
Programming Experience
10+
Okay,

I'm not exactly sure why this is occurring, and I believe it has something to do with Microsoft Office automation. My application basically Automates Word, Excel, and Outlook for use with facilitating many of my Team's daily functions. As a stickler about not doing tedious labor, I prefer to use computers to automate tasks I'd rather not use a pen for, and thus my Word Documents and Excel sheets can be populated via COM.

Granted, I am using SharpDevelop Open Source .Net IDE, but I figure I'd ask here as well as over there, to find out what exactly is causing the glitch. I run the program on my computer, the development system, all the time, and never have a problem. But now I'm getting ready to deploy, and it won't ever start on other systems.

Now, I use a few assemblies in my program, Shell32, Microsoft Word 11.0, Microsoft Excel 11.0, and Microsoft Outlook 11.0, and the compiler tends to include these "Interop.Word.dll" and other "Interop" dll files in my bin/Release directory. If those dll's are present the program runs on my system fine. If not, the program fails. However, if I copy those dll's to another system they don't work and I am curious as to why? Isn't there a way to access the COM functionality of Shell32 and specific Office Libraries without being machine specific? Is there some sort of "CopyRight" liscence code that is being compiled into the Dlls and thus not allowing the application to run?

Any help would be most appreciated.
Thanks
Jaeden "Sifo Dyas" al'Raec Ruiner
 
My FileSystemWatcher is initialized in the UnivForm.InitializeComponent() method, so this would occur before the Load event is triggered. Its Path property was set to folder location that might not exist on other systems. Would this cause the heinous InvalidOperationException? I'm thinking it might, but being that its the weekend I can't test this easily.
Thanks
Jaeden "Sifo Dyas" al'Raec Ruiner
That should have given ArgumentException, but you're right it throws InvalidOperationException (with ArgumentException inner), here a sample when I set this path to some random characters:
System.InvalidOperationException was unhandled
Message="An error occurred creating the form. See Exception.InnerException for details. The error is: The directory name C:\\axfvasd is invalid."
Source="WindowsApplication1"
StackTrace:
at WindowsApplication1.My.MyProject.MyForms.Create__Instance__[T](T Instance) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 190
at WindowsApplication1.My.MyProject.MyForms.get_Form1()
at WindowsApplication1.My.MyApplication.OnCreateMainForm() in D:\programmering\vbnet35\WindowsApplication1\WindowsApplication1\My Project\Application.Designer.vb:line 35
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)
at WindowsApplication1.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: System.ArgumentException
Message="The directory name C:\\axfvasd is invalid."
Source="System"
StackTrace:
at System.IO.FileSystemWatcher.set_Path(String value)
at WindowsApplication1.Form1.InitializeComponent() in D:\programmering\vbnet35\WindowsApplication1\WindowsApplication1\Form1.Designer.vb:line 316
at WindowsApplication1.Form1..ctor()
InnerException:
From this message it is possible for me to identify the problem and find exactly what line in code the error occurs:
at WindowsApplication1.Form1.InitializeComponent() in D:\programmering\vbnet35\WindowsApplication1\Windo wsApplication1\Form1.Designer.vb:line 316
Me.FileSystemWatcher1.Path = "C:\axfvasd"

Edit: I've been testing out different configurations a see that you probably got an error box at client where exception detail was not available, so you'd be happy to know there exist a place to get this info; even if this happens in InitializeComponent call the exception goes to Application event UnhandledException first, here you can log/display it. The line numbers of source code will not be available, but more info anyway, this was what I found when deployed:
System.InvalidOperationException: An error occurred creating the form. See Exception.InnerException for details. The error is: The directory name c:\xyz is invalid. ---> System.ArgumentException: The directory name c:\xyz is invalid.
at System.IO.FileSystemWatcher.set_Path(String value)
at WindowsApplication1.frmDiv.InitializeComponent()
at WindowsApplication1.frmDiv..ctor()
--- End of inner exception stack trace ---
at WindowsApplication1.My.MyProject.MyForms.Create__Instance__[T](T Instance)
at WindowsApplication1.My.MyApplication.OnCreateMainForm()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
So it's still possible to see that the problem is the path set for FileSystemWatcher in InitializeComponent.
 
Last edited:
When i try to play with the VisualBasic Express, it wants to add "Handles x.event" to every one of my events, removing the "AddHandler" statements in my *.Designer.vb files. Is this better/worse than using the AddHandler methodology?
Declaring a variable WithEvents have the convenience of allowing you to select any of its events in code editor and the handler method is generated, saves a lot of time and writing. All components added through Designer is declared this way in the generated .Designer.vb files. You can also dispose an object assigned to this variable and assign a new object, and same handlers will work for this without need for more code. Add/RemoveHandler must be used for objects created in code that is not assigned a WithEvents variable, here you can also dynamically detach/re-attach handlers. AddHandler sets a strong reference to the object, so if there are no other references and you miss to dispose it the object lives on. With AddHandler you also have to make sure you don't call it twice for same object/event else the handler is called twice also for each event raised.
 
Woohoo!!

Thank you very much for everything. Through out the teeth pulling, and whining, I have come to the answer and it was the FSW.Path property messing up the whole works. And wonderfully enough, I not only solved that issue, but was able to instill a generic Unhandled Exception handler, as well as setting up an Application File Logger as well for future debugging purposes. (Something i most likely would have wasted the time to write myself, never knowing such things already existed)

So,

Thank you very much for the help, and after all the time and effort it turns out to be one simple String property that screwed the pooch. *chuckle*

Regards,

Jaeden "Sifo Dyas" al'Raec Ruiner
 
Back
Top