Shadow Copy not behaving as expected

Mar 4, 2014 at 11:31 AM
Edited Mar 4, 2014 at 11:33 AM
Hi Govert.

very, very pleased with your DNA kit. A massive acheivement to be applauded.

There's nearly always are but ...

I've got an XLL [version 0.30, 64 bit] that's packed with about 23 other DLLs using the
<Reference Path="x.y.z.dll" Pack="true" />
element node in the dna file.

Top node is of the form

<DnaLibrary Name="Some add-in" RuntimeVersion="v4.0" ShadowCopyFiles="true">

Everything packs fine & the XLL runs like a dream.


However, I've placed the XLL on a server share, which works fine, apart from when I try to update the packed XLL file and I can't because a user has "connected" to it, and locked it from been copied over. So this doesn't look to work for me in terms of the ShadowCopyFiles doesn't prevent the XLL from locking & been copies over ?
Coordinator
Mar 4, 2014 at 12:08 PM
Edited Mar 4, 2014 at 12:31 PM
Hi,

I'm glad you find Excel-DNA useful.

The ShadowCopyFiles option does not apply to the native .xll library itself, nor to assemblies that are packed. It's not a feature I've used myself.

You won't be able to prevent Excel from locking the .xll file itself. Your network distribution scenario is typically addresses by doing something like this:

Don't do the single file packing (maybe it's not so important in your case, since you're not distributing the add-in). The .dna file outside the .xll is not locked and can be chained, so you might have different directories for each version of your add-in, then update the 'master' .dna file to point to a new version directory when you want to update. A user re-loading the .xll or opening it for the first time will get the new code. So you might have directories like this:

...\MyAddIn\MyMasterAddIn.xll
...\MyAddIn\MyMasterAddIn.dna
...\MyAddIn\v1\MyAddInV1.dna
...\MyAddIn\v1\MyAddInLib.dll
...\MyAddIn\v1\MyOtherLib.dll

And your initial version of MyMasterAddIn.dna would look like this:
<DnaLibrary RuntimeVersion... >
   <ExternalLibrary Path="v1\MyAddInV1.dna" />
</DnaLibrary>
while in ...\MyAddIn\v1\MyAddInV1.dna you have:
<DnaLibrary >
   <ExternalLibrary Path="MyAddInLib.dll" />
   <Reference Path="MyOtherLib.dll" />
</DnaLibrary>
Later you make a new version. Deploy like this:
...\MyAddIn\v2\MyAddInV2.dna
...\MyAddIn\v2\MyAddInLib2.dll
...\MyAddIn\v2\MyOtherLib.dll

with matching changes to ...\MyAddIn\v2\MyAddInV2.dna,

then update the ...\MyAddIn\MyMasterAddIn.dna to look like this:
<DnaLibrary RuntimeVersion... >
   <ExternalLibrary Path="v2\MyAddInV2.dna" />
</DnaLibrary>
(You can also just update the master MyMasterAddIn.dna file with the various paths, but this way seems a bit cleaner to me.)

A more sophisticated approach, if you have many add-ins and many versions, is to built an add-in manager, which is a 'master' add-in that manages which other add-ins are loaded. In this case you might store separate versions of your .xll file (perhaps packed) but have a master add-in that does not change, which loads the newest version.

I hope that gives you some ideas.

Regards,
Govert