[AccessD] Set references via automation

Gustav,

 > I thought you planned to make some kind of clean install where references were not set

No, the references being set are a requirement of development and removing them before putting them 
in the network location would require a utility to do that, or an intentional open and delete the 
references manually.

What I plan to do is save the path to the referenced libs (the source), then my CopyAndRun C# app 
would copy those libs to a c:\XYZ directory, then set up the references in the app to that C:\XYZ 
location.

Of course deleting them before I move them to the network location would prevent them from even 
opening (correctly) directly in that network location.  I am actually looking at a C# utility to 
push from dev to test and from test to production.  The reason is that, as I mentioned previously, 
an FE version is matched with a specific version of the framework.  What would be ideal is to zip up 
all the objects being pushed (so they could be restored if needed) and then copy the new objects in. 
  If I had that then I could remove the references as well.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 1/2/2012 8:15 AM, Gustav Brock wrote:
> Hi John
>
> I thought you planned to make some kind of clean install where references were not set - including the files for the libraries to be used - then add these libraries as references.
> Of course, if they are already there, you would need to delete them first - should be no big deal. But if you use a fixed path for the libraries, I don't see why it should be necessary to remove and re-add these.
>
> I don't know about macros run via automation or from the office tools for Visual Studio. By second thought, using the AutoExec macro was just convenient, it could be run from the opening form as well as long as it doesn't contain action code dependant on the new references. If so, you should be able to call the functions directly via the office tool, thus skipping the macro stuff - but again, I'm shooting in the wild, have never used it.
>
> /gustav
>
>
>>>> jwcolby at colbyconsulting.com 02-01-2012 13:39>>>
>   >  Then, I think, all you need is a function to add the references from the full paths:
>
> I assume I have to drop the old reference first.
>
>   >  and - when done - and this is the trick - one(1) function in a separate module to be used to
> compile and save all (other) modules:
>
> You don't think this can be done from the C# code as well?
>
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> On 1/2/2012 3:05 AM, Gustav Brock wrote:
>> Hi John
>>
>> Then, I think, all you need is a function to add the references from the full paths:
>>
>>     References.AddFromFile strFullPath1
>>     References.AddFromFile strFullPath2
>>     etc.
>>
>> and - when done - and this is the trick - one(1) function in a separate module to be used to compile and save all (other) modules:
>>
>> <vba>
>> Option Explicit
>>
>> Public Function CompileAndSave()
>>
>>     ' Compile and Save All Modules.
>>     ' The command:
>>     '   Application.RunCommand acCmdCompileAndSaveAllModules
>>     ' can not be used as no module is open.
>>     ' Thus, use undocumented SysCmd() call.
>>     Call SysCmd(504, 16483)
>>
>> End Function
>> </vba>
>>
>> Call these from the AutoExec macro as the first happening:
>>
>> RunCode: AddReferences ()
>> RunCode: CompileAndSave()
>>
>> This works with Access. I haven't tried (have no need) to run Access and call macros from C#.
>>
>> /gustav