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

Support for native binaries? #94

Closed
jazzdelightsme opened this Issue Dec 20, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@jazzdelightsme

jazzdelightsme commented Dec 20, 2016

I've got a .sln with both native (C/C++) and managed (C# and C++/CLI) projects. It would be great to also be able to stamp the native binaries with the same version information as the managed binaries. I'm not sure what the best way to implement this would be... perhaps to generate a .rc file, or to produce the .res file directly.

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Dec 21, 2016

Owner

Ooh, that's interesting. I'd be very interested in a pull request on this if someone can do it.

Owner

AArnott commented Dec 21, 2016

Ooh, that's interesting. I'd be very interested in a pull request on this if someone can do it.

@AArnott AArnott added the help wanted label Dec 21, 2016

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Dec 28, 2016

Contributor

I've got a pattern I can generalize and work on a code change here.

Contributor

heaths commented Dec 28, 2016

I've got a pattern I can generalize and work on a code change here.

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Dec 29, 2016

Owner

Thanks, @heaths

Owner

AArnott commented Dec 29, 2016

Thanks, @heaths

@jazzdelightsme

This comment has been minimized.

Show comment
Hide comment
@jazzdelightsme

jazzdelightsme Dec 30, 2016

Cool!

I happen to have some self-contained C# code that can emit a .res file containing version information (VS_FIXEDFILEINFO et al). I've used it in other, managed code projects where you couldn't depend on having rc.exe to compile a .rc to a .res. For an actual native code project, you could depend on being able to compile an .rc, but if I were to try to do this change, I don't know that it would be any less annoying to codegen a .rc file than it would to just create the .res file, given that I know how and already have code to do the latter. Also, since link.exe can accept multiple .res files, it's not a composition problem like it is for managed code (with csc.exe, you get one /win32res:file).

But after snooping around this project (NBGV) a bit, I've come to the conclusion that my msbuild-fu is far too weak, and given the amount of vacation time I have left, I don't think I'd be able to get very far. But @heaths, you are welcome to the .res-generating code if it is useful at all.

If generating the .res directly is interesting, another thought I had is maybe the .res-emitting code could/should be its own nuget package, since it's potentially useful in other projects. I could probably scrape that together.

Code here: https://gist.github.com/jazzdelightsme/844a5e6b97a58148767e01eb6dac5c9b

jazzdelightsme commented Dec 30, 2016

Cool!

I happen to have some self-contained C# code that can emit a .res file containing version information (VS_FIXEDFILEINFO et al). I've used it in other, managed code projects where you couldn't depend on having rc.exe to compile a .rc to a .res. For an actual native code project, you could depend on being able to compile an .rc, but if I were to try to do this change, I don't know that it would be any less annoying to codegen a .rc file than it would to just create the .res file, given that I know how and already have code to do the latter. Also, since link.exe can accept multiple .res files, it's not a composition problem like it is for managed code (with csc.exe, you get one /win32res:file).

But after snooping around this project (NBGV) a bit, I've come to the conclusion that my msbuild-fu is far too weak, and given the amount of vacation time I have left, I don't think I'd be able to get very far. But @heaths, you are welcome to the .res-generating code if it is useful at all.

If generating the .res directly is interesting, another thought I had is maybe the .res-emitting code could/should be its own nuget package, since it's potentially useful in other projects. I could probably scrape that together.

Code here: https://gist.github.com/jazzdelightsme/844a5e6b97a58148767e01eb6dac5c9b

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Dec 31, 2016

Owner

Personally, I favor NB.GV generating source code rather than a binary file so that folks can see what effect it's having on the build more clearly.

Owner

AArnott commented Dec 31, 2016

Personally, I favor NB.GV generating source code rather than a binary file so that folks can see what effect it's having on the build more clearly.

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Jan 1, 2017

Contributor
Contributor

heaths commented Jan 1, 2017

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Jan 1, 2017

Owner

Sweet!

Owner

AArnott commented Jan 1, 2017

Sweet!

robmen added a commit to robmen/Nerdbank.GitVersioning that referenced this issue Jun 15, 2017

Support GitVersioning in .vcxprojs
Generate a .rc file and include it into the build pipeline for native
code in a fashion similar to the `GenerateAssemblyVersionInfo` task.

Fixes #94

@AArnott AArnott closed this in #135 Jun 18, 2017

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Jun 19, 2017

Contributor

Seems we shouldn't close this until I merge my script changes with @robmen's changes to just support this. Right now, manual edits will be necessary unlike csproj or vbproj files.

Contributor

heaths commented Jun 19, 2017

Seems we shouldn't close this until I merge my script changes with @robmen's changes to just support this. Right now, manual edits will be necessary unlike csproj or vbproj files.

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Jun 19, 2017

Owner

@heaths are you talking about scripts to remove hard-coded versions from the project?
I don't consider those mandatory. And in fact modern nuget client scenarios like PackageReference and project.json don't execute those scripts anyway.
I'm willing to add the feature, but that would be a bonus rather than mandatory for this issue.

Owner

AArnott commented Jun 19, 2017

@heaths are you talking about scripts to remove hard-coded versions from the project?
I don't consider those mandatory. And in fact modern nuget client scenarios like PackageReference and project.json don't execute those scripts anyway.
I'm willing to add the feature, but that would be a bonus rather than mandatory for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment