config files problem

  • The Problem:

    I want to be able to use an assembly of an independant application

    which is not strong named from within an SSIS script component. I have

    created a wrapper assembly (Utils.dll) which is located in the same

    directory as it's dependant Dlls for this purpose and I'm calling it

    using reflection, example script code is:

    Dim UTILS as Assembly

    Dim tObject As Type

    Dim TheObject as Object

    UTILS = Assembly.LoadFrom("D:\\Development\\TestApp\\Utils\\bin

    \\Debug\\Utils.dll")

    tObject = LILI_UTILS.GetType("Utils.Data.TheObject")

    TheObject = tObject .InvokeMember("TheObject",

    BindingFlags.CreateInstance, Nothing, Nothing, Nothing)

    TheObject.Validate(SomeData)

    Although I can call the Validate method, the Validate method uses an

    object in this external application assembly, but that object is

    reporting that it can't find a certain entry in the config file which

    I assume is because it's looking at one of the config files in "C:

    \Program Files\Microsoft SQL Server\90\DTS\binn\" rather than it's

    specific config file. This is backed by the fact that examining the

    AppDomain.CurrentDomain object shows that the BaseDirectory is "C:

    \Program Files\Microsoft SQL Server\90\DTS\binn\".

    Now I don't know the ins and outs of this external application and I

    don't have control of it, in fact it has about 50 of it's own config

    files so I don't want to mess about with config structures. Is it

    possible to make the working folder for SSIS different to "C:\Program

    Files\Microsoft SQL Server\90\DTS\binn\"? Would this even work or is

    there another way of making the correct config information being

    picked up?

    If anyone has any ideas it would be much appreciated, I really could

    do with finding a way to use aspects of this external system without

    knowing everything about it, there are so many dlls and configurations

    of this external app that I just don't know about.

    thanks

    Hoots.

  • If you try running DTEXECUIdtexecui from a command line who's path is what you want? Just a shot in the dark...

    Cheers,CrispinI can't die, there are too many people who still have to meet me!It's not a bug, SQL just misunderstood me!

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply