"Chubbly Geezer" <chubbly_geezer@newsgroup.nospam> wrote in message
news:OIECPlXiGHA.2456@TK2MSFTNGP04.phx.gbl...
> Now I'm coming from a VB6 background so I may be overlooking something
> here.
>
> I have functionality that is contained with 2 VB 2005 dll's.
>
> WARC_Subs_Reporting.dll which handles report functions and has a reference
> to WARC_Standard_Functions which holds the day to day functionality and
> has references to Microsoft.Practices.EnterpriseLibrary.Data.dll and
> Microsoft.Practices.EnterpriseLibrary.Common.dll
>
> I want WARC_Subs_Reporting.dll available to MS Access 2003 and so have
> assigned Strong Names to all of the above.  I have created an install
> routine for WARC_Subs_Reporting.dll which then has the other 3 named dll's
> as references.  The install when run installs all 4 dll's to the correct
> directory.  I then add WARC_Subs_Reporting.dll to the GAC as it is the
> only dll I require to access from COM.
>
> I've now created a dummy VB 2005 project to test the installed dll.  When
> I step through, it calls a procedure within WARC_Subs_Reporting.dll, which
> calls a procedure within WARC_Standard_Functions that creates a dataset by
> using the procedures within the DAAB.  However, it always falls over on
> the following line of code within the DAAB:
>
> return EnterpriseLibraryFactory.BuildUp<T>(name, configurationSource);
>
> within the 'public T Create(string name)' procedure within the
> 'NameTypeFactoryBase' class.
>
> Giving this error:
>
> The type initializer for
> 'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory'
> threw an exception.
>
> Now, to be honest, I have no idea what this is and cannot find any useful
> help on the matter.  Any ideas.
>
> Thanks
>
> Chubbly
>

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:eoOf7pXiGHA.3780@TK2MSFTNGP03.phx.gbl...
> Chubbly,
>
>    Have you tried to debug this?  There should also be information in the
> Message property of the exception.  Also, be sure to check the
> InnerException property.  It looks like there is a static constructor for
> the
> Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory
> class which is throwing an exception.
>
>    Also, a comment on your installation.  While you might only be exposing
> classes from one assembly in the GAC, you should have all of the
> references that the assembly has in the GAC as well.  It doesn't make
> sense to have just the one assembly in the GAC and the others be private,
> when you know that it will require those references.
>
>    The idea here is to distrubute those assemblies as a logical unit,
> which you are currently breaking up.
>
>    Adding them to the GAC won't make them visible to COM, it will just
> enforce that logical unit.
>
>    Hope this helps.
>
> --
>          - Nicholas Paldino [.NET/C# MVP]
>          - mvp@spam.guard.caspershouse.com
>
>
> "Chubbly Geezer" <chubbly_geezer@newsgroup.nospam> wrote in message
> news:OIECPlXiGHA.2456@TK2MSFTNGP04.phx.gbl...
>> Now I'm coming from a VB6 background so I may be overlooking something
>> here.
>>
>> I have functionality that is contained with 2 VB 2005 dll's.
>>
>> WARC_Subs_Reporting.dll which handles report functions and has a
>> reference to WARC_Standard_Functions which holds the day to day
>> functionality and has references to
>> Microsoft.Practices.EnterpriseLibrary.Data.dll and
>> Microsoft.Practices.EnterpriseLibrary.Common.dll
>>
>> I want WARC_Subs_Reporting.dll available to MS Access 2003 and so have
>> assigned Strong Names to all of the above.  I have created an install
>> routine for WARC_Subs_Reporting.dll which then has the other 3 named
>> dll's as references.  The install when run installs all 4 dll's to the
>> correct directory.  I then add WARC_Subs_Reporting.dll to the GAC as it
>> is the only dll I require to access from COM.
>>
>> I've now created a dummy VB 2005 project to test the installed dll.  When
>> I step through, it calls a procedure within WARC_Subs_Reporting.dll,
>> which calls a procedure within WARC_Standard_Functions that creates a
>> dataset by using the procedures within the DAAB.  However, it always
>> falls over on the following line of code within the DAAB:
>>
>> return EnterpriseLibraryFactory.BuildUp<T>(name, configurationSource);
>>
>> within the 'public T Create(string name)' procedure within the
>> 'NameTypeFactoryBase' class.
>>
>> Giving this error:
>>
>> The type initializer for
>> 'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory'
>> threw an exception.
>>
>> Now, to be honest, I have no idea what this is and cannot find any useful
>> help on the matter.  Any ideas.
>>
>> Thanks
>>
>> Chubbly
>>
>
>

"Chubbly Geezer" <chubbly_geezer@newsgroup.nospam> wrote in message
news:%233vZ5QYiGHA.1276@TK2MSFTNGP03.phx.gbl...
> Nicolas
>
> thanks for the quick response.
>
> I am unable to find any info on the inner exception, but copying this
> error to the clipboard produces the following:
>
> System.TypeInitializationException was unhandled
>  Message="The type initializer for
> 'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory'
> threw an exception."
>  Source="Microsoft.Practices.EnterpriseLibrary.Common"
>
> TypeName="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory"
>  StackTrace:
>       at
> Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory.BuildUp[T](String
> id, IConfigurationSource configurationSource)
>       at
> Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.NameTypeFactoryBase`1.Create(String
> name)
>       at
> Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase(String
> name)
>       at SharedFunctions.clsConnection.CreateDataset(String strSQL, String
> conn)
>       at WARC_Subs_Reporting.modRenewal.AgentsRenewalsCheck()
>       at WARC_Subs_Reporting.clsPublic.AgentsRenewal()
>       at WindowsApplication3.Form1.Button1_Click(Object sender, EventArgs
> e) in C:\temp\2005\WindowsApplication3\WindowsApplication3\Form1.vb:line 8
>       at System.Windows.Forms.Control.OnClick(EventArgs e)
>       at System.Windows.Forms.Button.OnClick(EventArgs e)
>       at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
>       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons
> button, Int32 clicks)
>       at System.Windows.Forms.Control.WndProc(Message& m)
>       at System.Windows.Forms.ButtonBase.WndProc(Message& m)
>       at System.Windows.Forms.Button.WndProc(Message& m)
>       at
> System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
>       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
> m)
>       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd,
> Int32 msg, IntPtr wparam, IntPtr lparam)
>       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
> msg)
>       at
> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
> dwComponentID, Int32 reason, Int32 pvLoopData)
>       at
> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> reason, ApplicationContext context)
>       at
> System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
> reason, ApplicationContext context)
>       at System.Windows.Forms.Application.Run(ApplicationContext context)
>       at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
>       at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
>       at
> Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[]
> commandLine)
>       at WindowsApplication3.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()
>
> with which I am totally lost.  I can see where the error is happening but
> not too sure how to resolve.
>
> Chubbly
> "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote
> in message news:eoOf7pXiGHA.3780@TK2MSFTNGP03.phx.gbl...
>> Chubbly,
>>
>>    Have you tried to debug this?  There should also be information in the
>> Message property of the exception.  Also, be sure to check the
>> InnerException property.  It looks like there is a static constructor for
>> the
>> Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory
>> class which is throwing an exception.
>>
>>    Also, a comment on your installation.  While you might only be
>> exposing classes from one assembly in the GAC, you should have all of the
>> references that the assembly has in the GAC as well.  It doesn't make
>> sense to have just the one assembly in the GAC and the others be private,
>> when you know that it will require those references.
>>
>>    The idea here is to distrubute those assemblies as a logical unit,
>> which you are currently breaking up.
>>
>>    Adding them to the GAC won't make them visible to COM, it will just
>> enforce that logical unit.
>>
>>    Hope this helps.
>>
>> --
>>          - Nicholas Paldino [.NET/C# MVP]
>>          - mvp@spam.guard.caspershouse.com
>>
>>
>> "Chubbly Geezer" <chubbly_geezer@newsgroup.nospam> wrote in message
>> news:OIECPlXiGHA.2456@TK2MSFTNGP04.phx.gbl...
>>> Now I'm coming from a VB6 background so I may be overlooking something
>>> here.
>>>
>>> I have functionality that is contained with 2 VB 2005 dll's.
>>>
>>> WARC_Subs_Reporting.dll which handles report functions and has a
>>> reference to WARC_Standard_Functions which holds the day to day
>>> functionality and has references to
>>> Microsoft.Practices.EnterpriseLibrary.Data.dll and
>>> Microsoft.Practices.EnterpriseLibrary.Common.dll
>>>
>>> I want WARC_Subs_Reporting.dll available to MS Access 2003 and so have
>>> assigned Strong Names to all of the above.  I have created an install
>>> routine for WARC_Subs_Reporting.dll which then has the other 3 named
>>> dll's as references.  The install when run installs all 4 dll's to the
>>> correct directory.  I then add WARC_Subs_Reporting.dll to the GAC as it
>>> is the only dll I require to access from COM.
>>>
>>> I've now created a dummy VB 2005 project to test the installed dll.
>>> When I step through, it calls a procedure within
>>> WARC_Subs_Reporting.dll, which calls a procedure within
>>> WARC_Standard_Functions that creates a dataset by using the procedures
>>> within the DAAB.  However, it always falls over on the following line of
>>> code within the DAAB:
>>>
>>> return EnterpriseLibraryFactory.BuildUp<T>(name, configurationSource);
>>>
>>> within the 'public T Create(string name)' procedure within the
>>> 'NameTypeFactoryBase' class.
>>>
>>> Giving this error:
>>>
>>> The type initializer for
>>> 'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder.EnterpriseLibraryFactory'
>>> threw an exception.
>>>
>>> Now, to be honest, I have no idea what this is and cannot find any
>>> useful help on the matter.  Any ideas.
>>>
>>> Thanks
>>>
>>> Chubbly
>>>
>>
>>
>
>

"Chubbly Geezer" <chubbly_geezer@newsgroup.nospam> wrote in message
news:OIECPlXiGHA.2456@TK2MSFTNGP04.phx.gbl...
> Now I'm coming from a VB6 background so I may be overlooking something
here.
>
> I have functionality that is contained with 2 VB 2005 dll's.
>
> WARC_Subs_Reporting.dll which handles report functions and has a reference
> to WARC_Standard_Functions which holds the day to day functionality and
has
> references to Microsoft.Practices.EnterpriseLibrary.Data.dll and
> Microsoft.Practices.EnterpriseLibrary.Common.dll
>
> I want WARC_Subs_Reporting.dll available to MS Access 2003 and so have
> assigned Strong Names to all of the above.  I have created an install
> routine for WARC_Subs_Reporting.dll which then has the other 3 named dll's
> as references.  The install when run installs all 4 dll's to the correct
> directory.  I then add WARC_Subs_Reporting.dll to the GAC as it is the
only
> dll I require to access from COM.
>
> I've now created a dummy VB 2005 project to test the installed dll.  When
I
> step through, it calls a procedure within WARC_Subs_Reporting.dll, which
> calls a procedure within WARC_Standard_Functions that creates a dataset by
> using the procedures within the DAAB.  However, it always falls over on
the
> following line of code within the DAAB:
>
> return EnterpriseLibraryFactory.BuildUp<T>(name, configurationSource);
>
> within the 'public T Create(string name)' procedure within the
> 'NameTypeFactoryBase' class.
>
> Giving this error:
>
> The type initializer for
>

> threw an exception.
>
> Now, to be honest, I have no idea what this is and cannot find any useful
> help on the matter.  Any ideas.
>
> Thanks
>
> Chubbly
>
>