Problem with packing

[ajwillshire]

Hi,

I think I'm misunderstanding the packing process.

I've got my external library .dll file, my .dna file, the
ExcelDNA.Integration.dll file, the ExcelDNA.xll file and the
ExcelDNAPack.exe in a directory.

If I go to the command prompt and the correct directory and type in
"ExcelDNAPack.exe Test1.dna" then I get the error message "Base add-in
not found".

What am I doing wrong?

Thanks,
Andrew

[Govert van Drimmelen]

Hi Andrew,

It ounds like you are doing everything right, and it should work.

The packer looks for a file called "ExcelDna.xll" in the following two
places:
1. same directory as the .dna file, and
2. same directory as the ExcelDnaPack.exe file.
and gives the error message you report if it can't find it in either
place.

What might be wrong?
* Maybe the ExcelDna.xll has been renamed? It should still be called
"ExcelDna.xll" for the packing to work.
* Explorer is hiding extensions, and the file has an extra extension
you can't see - check using "dir" from the command prompt.

Write back if we need to look a bit closer.

Regards,
Govert

[ajwillshire]

Hi Govert,

Yes, that was my mistake. I had renamed the ExcelDNA.xll.

Thanks,
Andrew

> > Andrew- Hide quoted text -
>
> - Show quoted text -

[Govert van Drimmelen]

Hi Andrew,

Do you think it makes more sense to look for it as MyProject.xll? That
way it pack a working set of MyProject.xll, MyProject.dna and
OtherLib.dll into MyProject-packed.xll.

I could look for both - which should I prefer if there is both an
ExcelDna.xll and a MyProject.xll?

Regards,
Govert

[Ed Parcell]

Hi Govert,

I ran across the same issue while converting a non-packed project to use packing. I think as long as it is clear somewhere (I found out by looking at the examples) that non-packed projects look for MyProject.xll, and packed projects look for ExcelDna.xll, then it is fine. Maybe if there are strong opinions both ways it would be better to have a flag to ExcelDnaPack to say which to use, rather than implicitly trying a few "reasonable" things, which may be confusing to the user unless they open up the source?

On the subject, if you're open to additional flags on ExcelDnaPack, one that would be useful to me would be to specify the output file. If you're open to that, let me know and I'll try to get a patch to you.

Best regards,

Ed.

--
You received this message because you are subscribed to the Google Groups "Excel-Dna" group.
To post to this group, send email to exce...@googlegroups.com.
To unsubscribe from this group, send email to exceldna+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/exceldna?hl=en.

[ajwillshire]

Yes, I think it would make sense to look for the file renamed to match
the DNA file.

I suspect most people get their project working using the separate
class library, dna file and renamed ExcelDNA.xll. Once it is working
and ready for distribution then currently they have to rename their
xll back to ExcelDNA.xll for the packager.

I don't know how easy it is but perhaps giving the Packager file a
simple userform to select the files in the directory might be useful.

On a related point, is the packager able to pick up external libraries
that are referred to by the MyProject library? I am hoping to refer to
the MathNet.Numerics library (have you seen it? very useful!) from the
MyProject.dll and I was wondering if packaging the Xll absorbs that
additional external library.

Thanks,
Andrew

> > > - Show quoted text -- Hide quoted text -

[Govert van Drimmelen]

Hi Ed,

Yes - overriding the default output path with a switch would be great
- please send a patch by email.

While you're at it, could you try to extend the check for the .xll to
look for <MyProject>.xll too? Rather than have lots of switches, I'd
prefer it to work the first time someone tries? (And for the existing
stuff to keep working.)

Regards,
Govert

> > exceldna+u...@googlegroups.com<exceldna%2Bunsubscribe@googlegroups.c om>
> > .

[Govert van Drimmelen]

Hi Andrew,

You should indeed be able to pack the MathNet.Numerics into your .xll.
The packer should add assemblies for which you have <Reference ....
Pack="true"> tags in the .dna file, though I'm not sure I've tested
the resolution scenario properly. Let me know if it doesn't work for
you. Remember to not have the referenced assembly in the GAC when
you're testing.

You can see in the output of ExcelDnaPack.exe which assemblies are
packed.

Regards,
Govert

> > > exceldna+u...@googlegroups.com<exceldna%2Bunsubscr...@googlegroups.c om>

[Alain Bryden]

Something that might help future visitors:

As Govert said, the default behaviour is first to look in:

1. same directory as the .dna file, and
2. same directory as the ExcelDnaPack.exe file.

If you're trying to publish a 64 bit version of the add-in, you cannot let #2 happen, so you have to make a copy of ExcelAddin64.xll in the same directory as your MyAddin64.dna file.

As of the time of this post, to support both 32 bit and 64 bit excel, The NuGet package for ExcelDNA automatically adds following post-build steps:

(copy the *.dna config file to *64.dna so that it can be used by ExcelDnaPack to make a 64 bit version.)
xcopy "$(TargetDir)${projName}-AddIn.dna" "$(TargetDir)${projName}-AddIn64.dna*" /C /Y

(copy the ExcelDna.xll and 64 bit xlls so they can be used by ExcelDnaPack to make the packaged addins.)
xcopy "$(SolutionDir)packages\(etc)\ExcelDna.xll" "$(TargetDir)${projName}-AddIn.xll*`" /C /Y
xcopy "$(SolutionDir)packages\(etc)\ExcelDna64.xll" "$(TargetDir)${projName}-AddIn64.xll*`" /C /Y

(run DnaPack on both files to create the 32 and 64 bit addins)
"$(SolutionDir)packages\(etc)\ExcelDnaPack.exe" "$(TargetDir)${projName}-AddIn.dna"
"$(SolutionDir)packages\(etc)\ExcelDnaPack.exe" "$(TargetDir)${projName}-AddIn64.dna"


If you think anything like me, you didn't want your add-in named "whatever-packed.xll", you wanted it named "whatever.xll". So you take advantage of the "/O" flag that Govert kindly added to control the name of the output file:

Note: This is wrong, do not replicate:
"$(SolutionDir)packages\(etc)\ExcelDnaPack.exe" "$(TargetDir)${projName}-AddIn.dna" /O "$(TargetDir)${projName}-AddIn.xll" /Y
"$(SolutionDir)packages\(etc)\ExcelDnaPack.exe" "$(TargetDir)${projName}-AddIn64.dna" /O "$(TargetDir)${projName}-AddIn64.xll" /Y

Suddenly, your 64 bit add-in is still getting generated, but you start getting the classic error: "The file you are trying to open "MyAddin64.dll" is in a different format than specified by the file extension. Verify the file is not corrupted and from a trusted source before opening the file. Do you want to open the file now?"

It's subtle, but what after much debugging and reading the ExcelDnaPack code, it turns out that this is all the fault of the way that "/Y" flag is implemented. Here's what happens:

1. You correctly copy the ExcelDna64.xll file to your build directory as MyAddIn-AddIn64.xll (and the .dna config file). So far so good.
2. ExcelDnaPack is run against MyAddIn-AddIn64.dna
3. ExcelDnaPack sees you wish to save your file as MyAddIn-AddIn64.xll - sure, no problem.
4. ExcelDnaPack sees the file MyAddIn-AddIn64.xll already exists - of course it does. You copied it there from the base ExcelDna64.xll (exactly as the default post-build script does) with the intent to overwriting it with a packed version. To you, this seems natural, but...
5. ExcelDnaPack deletes the file MyAddIn-AddIn64.xll (so that it can create a new file there)
6. Only now does ExcelDnaPack look for an .xll in the same directory as your .dna file with the same name. It was there, but the /Y option just deleted it.
7. Since it couldn't find MyAddIn-AddIn64.xll, it goes on over to the 'packages' directory (which is the fallback behavior) and grabs ExcelDna.xll, which is the wrong bitness. (that's an actual word by the way :p)
8. You now have your shiny new MyAddIn-AddIn64.xll in your debug folder, but it is actually a 32 bit add-in. Whoops.

This problem can be resolved/prevented by changing ExcelDna a number of ways:
- One way (and Govert has clearly considered this according to comments in the code) is to delete the fallback behavior of using the package ExcelDna.xll. This will avoid the need to try to encode logic about whether to use the 32 bit or 64 bit version and force the user to ensure the correct file is alongside their dna file.
- Change the behavior of the /Y flag. Instead of deleting the target file upfront, first generate the packed xll to a temporary file (microsoft software commonly does this by creating a file starting with ~), then overwrite the file at the very end. This will allow the same file to be used as an input, and then overwritten (which I feel might be a common desire).
- Make the input xll file an optional parameter. (like /I). If the user explicitly passes this, then the tool shouldn't attempt to use any "Fallback" strategy for picking an xll file, which can avoid confusion such as the above situation.


As a workaround, the solution to this is to either manually rename the output file, or change the file names of the transient input dna and xll file names, and optionally delete them after ExcelDnaPack is run, so a developer doesn't get confused about which add-in they should be pulling out of the build artifacts.

Here's my final Post-build events:

REM Copy the dna configuration file and name it so that it is used for the 64 bit version of the add-in.
xcopy "$(TargetDir)internalName.dna" "$(TargetDir)internalName64.dna*" /C /Y

REM Copy the template add-in and 64 bit version to the build directory.
xcopy "$(SolutionDir)packages\Excel-DNA.0.32.0\tools\ExcelDna.xll" "$(TargetDir)internalName.xll*" /C /Y
xcopy "$(SolutionDir)packages\Excel-DNA.0.32.0\tools\ExcelDna64.xll" "$(TargetDir)internalName64.xll*" /C /Y

REM Pack the add-in and 64 bit add-in with their dependencies so that it is a standalone add-in.
"$(SolutionDir)packages\Excel-DNA.0.32.0\tools\ExcelDnaPack.exe" "$(TargetDir)internalName.dna" /O "$(TargetDir)MyAddin.xll" /Y
"$(SolutionDir)packages\Excel-DNA.0.32.0\tools\ExcelDnaPack.exe" "$(TargetDir)internalName64.dna" /O "$(TargetDir)MyAddin64.xll" /Y

REM Delete the no longer necessary DnaPack source files
del /Q "$(TargetDir)internalName*.dna"
del /Q "$(TargetDir)internalName*.xll"

[Govert van Drimmelen]

Hi Alain,

 

Thank you for this detailed write-up and analysis!

 

Do I understand right, that if your initial approach using /O used the name “whatever.xll” instead of “whatever-addin.xll”, then everything would work have worked fine?

Another user suggested using an MsBuild  .targets file to drive the ExcelDnaPack.exe run, rather than the post-build steps. That sounds like a good idea, but I’ve not been able to figure out how to do it yet.

 

I like your suggestion to remove the automatic fallback behaviour but add an explicit /I switch. I see ExcelDnaPack as a tooling utility, and am OK if it falls apart under edge cases. In your example failing would have been better than generating the .xll with the unexpected bitness.

 

Would you perhaps like to make this change to ExcelDnaPack as a pull request on the GitHub repository (https://github.com/Excel-DNA/ExcelDna)? I’m slowly moving the development there, and both the workflow and git is still very new to me, so I’m keen to practise (but carefully).

 

-Govert

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.

To post to this group, send email to exce...@googlegroups.com.

Visit this group at http://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.