New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically replace XLL version information with data read from an assembly #15
Comments
I think it's a good idea, but not something I'm likely to work on myself anytime soon. Is there a standard MSBuild task that can do a version update for a .dll? If not, I think the code for the version update would fit well into the ExcelDnaPack executable, since that already modifies the .xll file. Maybe ExcelDnaPack should have an option to update the Version resource only (without packing the .dna file). That would eliminate the need for another binary to update the Version resource, but still give you the option to only do a version update. I would like to discuss details of the .dna changes before you implement that aspect. What attributes do you plan to add etc... |
Hi Govert, I understand this is not in your short-term roadmap, which is why I added the issue here to surface it to others as you said you'd be open to a PR (I'll take a stab on this in a few days, if no one does). I'm not aware of any built-in MSBuild task that can do that. I was thinking about implementing a custom one that would be included in the NuGet package and run as part of the build (via a custom build target). This MSBuild task would just modify the version resource of the .XLL file(s) to set the corresponding version info, all using Windows APIs, similar to what you already do in ExcelDnaPack. Regarding changes to the .dna file, I was thinking about adding a new attribute (name to be defined) to the "DnaLibrary" tag, that would tell the MSBuild task to use that assembly to read version information. e.g.
Or alternatively, add an attribute to the "ExternalLibrary" tag. e.g.
I prefer something along the lines of the the first approach as it is more clear/direct. The second approach would allow a developer to add the same attribute to multiple tags, and we would have to define some rules to pick which one to use, etc. Thanks, |
I don't know how the MSBuild task would call the Windows APIs, but I'm suggesting that instead of an extra .dll for the build task, that those API calls go into ExcelDnaPack. Then MSBuild could call ExcelDnaPack with some parameters to update the Version. But I'm open to other ideas. In fact, what I think would be first prize is for all the packing calls to made via build targets, thus replacing the post-build events that do the packing now. But I've not been brave enough to figure out the build targets yet. I'm fine with the .dna file getting the extra attribute as you suggest - I agree adding to the DnaLibrary tag makes more sense. |
I suggest this sequence of work items:
|
@augustoproiete I understand that making a separate .dll file with build tasks is probably the end goal. I'm just trying to sequence things so that I can live with the intermediate states. If you're OK doing the version stuff first, then I suggest doing it inside ExcelDnaPack first, and leaving the refactoring for later. Something like the sequence I suggest here. Otherwise, you might like to do the refactoring clean-up of ExcelDnaPack first, into a .dll (ExcelDna.Build.dll ?) which does all the work (and could be used to host build tasks), and a small command-line executable ExcelDnaPack.exe around it. For this step the main issue would probably be to sort out all the messages and stuff. So I'm OK with either direction, just not the hybrid where some build stuff is in a .dll and some still in the executable. |
@govert: Thanks. The sequence you propose above is fine, especially if I was tackling this issue in isolation, and it would make sense to extend ExcelDnaPack first (quick win) and later worry about wrapping it into an MSBuild task + console app. No worries there. However, in terms of priority, I think #18 and #19 are much more important - currently a pain for many devs, which makes debugging harder. I'd rather spend time on #18 and #19 next (after we finalize #17) and leave this issue here for later. What do you think? Maybe we go with a variation of your second suggestion, and try to wrap ExcelDnaPack into an MSBuild task doing the minimum amount of refactoring possible. Just enough to make it work (whilst I work on #18 and #19), and leave refactoring for another issue? |
@augustoproiete Your help is greatly appreciated, and of course you can take on the issues in the sequence that would help you most. Having said that, I've been asked about the version things about five times. I've never had a single question about the debug startup stuff in #18, and #19. I'm also not sure how you'd approach #18 - I don't know if it's just another MSBuild property and the issue is just finding the right path, or whether it requires some other way of updating the project files. MSBuild has build-in tasks for running executables. So if ExcelDnaPack.exe is able to update the version, then getting it to run as part of the build should be easy with no custom build task library. Or is there something I'm missing? |
@govert / @augustoproiete -- Versioning the xll for Windows Installer would be super helpful for us. We need to manage publishing of various add-ins and versions thereof. If we could resolve this during packing and have the .xll indicate the version of a packed binary then that would be awesome. Any idea on if and when this feature would be available? |
@davidandersen It's not something I'm planning to do at this stage, but I'd be happy to accept a contribution for this. I suggest the first step for this would be to implement it as a switch in ExcelDnaPack, which updates the version resource in the .xll, taking the path of a .dll to use. Would that work for your case? Alternatively, it might be possible to add a call to a utility like verpatch in you post-build script. |
Some thoughts, just to add to the conversation:
Maybe we just change the C++ project to include a new resource e.g. "dna_version" which by default is the same as the version resource. Therefore nothing special needs to be done by ExcelDnaPack to keep the "dna_version" there. |
I agree with the first point - so maybe ExcelDnaPack is not the right place. I now (finally?) agree that the ExcelDnaPack code should probably go in there too, leaving ExcelDnaPack.exe as a thin wrapper that just calls the library. I'll have to think about the ExcelDna version. Maybe it can just be a comment or description written in the regular version resource. On 19 May 2016, at 01:35, Caio Proiete <notifications@github.commailto:notifications@github.com> wrote: Some thoughts, just to add to the conversation:
ExcelDnaPack.exe update-file-version MyAddIn.xll So maybe we just change the C++ project to include a new resource to "dna_version" which by default is
ExcelDnaPack.exe show-file-version MyAddIn.xll — |
Indeed, looks like we have a few options to choose in the We'll have to decide which one is best. |
Hi augustoproiete, you can just use that tool as a build task: All the other ways doesn't make sense in my eyes, because nobody want to compile the xll on every build again. bye Konrad |
@konne The idea is certainly not to recompile the .xll. It's just about updating the embedded version resource, similar to how ExcelDnaPack updates embedded resources. Something that would work in a post-build step at the moment is using a powershell command or something to read the version from the managed assembly, and pipe that to the verpatch tool. I think @augustoproiete and @davidandersen are just looking for something a bit more elegant to set up in their (many?) add-ins. |
|
@augustoproiete and @govert Then next issues is how the dll is defined who contains the version infos. For example I pack all in all 20 dlls into the xll. What are your ideas? |
Interesting. I haven't looked at the source of verpatch until you mentioned it, and I thought it was simpler (i.e. calling a Win32 API or two), but you're right, it will def. be tricky to implement all that in C#. Assuming there is indeed no Win32 API to do that, maybe the easiest thing for us would be to absorb the verpatch code in C++ as is, but turn it into a Win32 DLL, so that we can call via P/Invoke from ExcelDnaPack (or the MSBuild task down the road). We can include this "verpatch.dll" in the NuGet package, or we can embed it in the ExcelDnaPack executable (or, again, the MSBuild task down the road).
I was thinking about adding a new attribute (name to be defined) to the "DnaLibrary" tag, that would tell the MSBuild task to use that assembly to read version information. e.g.
|
If you provide me the verpatch as dll, I can update the ExcelDNAPack |
I can't image it being hard to do in C# - ExcelDnaPack does pretty much the same thing with updating resources already. I'd certainly not want that part to be in C++, or incorporate code from the verpatch project. What about an attribute on the ExternalLibrary (and we use the first/last): <DnaLibrary Name="MyAwesomeExcelAddIn">
<ExternalLibrary Path="MyXLAddInAssembly.dll" LoadFromBytes="true" AddInVersion="true" />
</DnaLibrary> That way we don't have to repeat the name? |
@govert -- I like that. That makes sense. For what it's worth all that we're doing right now is calling a post-build executable that wraps verpatch and we add that to the end of the post-build events in Visual Studio. It looks something like below. "$(BuildRoot)Tools\ExcelDnaPostBuild.exe" -p "$(TargetDir)SomethingCooler-AddIn64-packed.xll" -v "$(TargetDir)SomethingCool.dll" -n "Something Different" Where: -p -- the packed .xll for which we want to update version -v -- the file from which to pull the version information -n -- (optional) an alternative name for the final packed .xll In the end, the above creates a new .xll named This is pretty ugly and not as elegant as having Excel DNA taking care of this natively, but it does the trick. btw -- this is really great stuff. Thanks. |
Here's one example of a C# library for updating version (and other) On the other hand, I find the one-line solution of @davidandersen rather attractive. Maybe we just need to document it somewhere? |
@govert thanks for the lib. I don't like the other approach to have a seperate tool (like davidandersen) |
@govert / @konne -- I'm not a huge fan of what we're currently doing either, and would much rather have it native to ExcelDnaPack. On a related note, one thing that I think would be nice is to move all of the post-build events to a single executable, perhaps named something like ExcelDnaPostBuild, and requiring minimal inputs. |
@davidandersen The work that @augustoproiete has done in #27 on the build is the first step to an improved build story, removing the post-build event and replacing with custom build targets with tasks in the new ExcelDna.AddIn.Tasks library. It's probably the right place for this too. |
I wonder where can I get this ExcelDnaPostBuild.exe tool? Or is it already superseded? |
The only update I have on this issue is that the new post-build approach and its ExcelDna.AddIn.Tasks library are now in the master branch (and the v 0.34 beta test). That doesn't (yet) contain anything like the version updating. |
This issue is partially resolved with PR #114. It introduces a new (optional) attribute in the It also updates the XLL file resulting from running The only thing left to close this issue, is to perform the same operation above as part of the build, so that the XLL files copied to the output folder also have the version of the assembly indicated (if any) - when the user is not using |
@augustoproiete, cool. Is this feature included in the build 0.34.4-rc3? |
@fandrei Yes, it is included. The NuGet package Let us know if you find any bugs! |
@augustoproiete, unfortunately I can't get it working. I've added a UseVersionAsOutputVersion="true" attribute to ExternalLibrary of my primary assembly, but the resulting packed xll doesn't contain any version number. |
@fandrei How are you checking? |
Ah I see, thanks. |
@govert As per my comment above, the We should either re-open this issue or create a new one to track that. |
@augustoproiete OK - I'll reopen it, but the packing case seemed like the important one. |
This is a (slightly modified) feature request that was asked in the mailing-list, so just adding as an issue so we can track this better and possibly encourage someone to implement and send a PR.
Original requests:
My assumption is that the developer (or ideally the continuous integration system) should be responsible for setting the right version information about the add-in, in the main assembly (or in all of them). With that said, we should be able to describe in the Excel-DNA XML file which assembly should be used to read version information about the add-in (version number, copyright, product name, etc.) and any information available in this assembly should automatically replace what is in the XLL file, during the build of the project.
I would suggest this to be implemented as a regular MSBuild Task, rather than implementing this as part of the ExcelDnaPack utility given that people might not care about packing their add-ins - and still would like to get version information in the XLL that gets copied during the build.
The text was updated successfully, but these errors were encountered: