-
Notifications
You must be signed in to change notification settings - Fork 52
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
Update projects and NuGet packages to target Excel-DNA v1.0.0 #84
Update projects and NuGet packages to target Excel-DNA v1.0.0 #84
Conversation
So my thought would be - why? I guess in Registration that didn't occur because the version number was old there. |
IntelliSense has extra version stuff in the code (not from the assembly version) that ensures only one server is loaded in the process. We need to review that and update too. |
Main reason: If IntelliSense is being installed from an add-in (Integrated display server: ExcelDna.IntelliSense.dll library) my understanding is that they should both reference the same version of If the above is true, then I'd expect an updated release of Once the signed version of |
Really? Where is that? I don't see any hard-coded version number of anything like that. I also looked at commit 994749a where you bumped the version from |
My understanding is that a new add-in (v1.0.0) can use the current IntelliSense (built targeting older Integration) without problems. Am I wrong? I can't check now. Version stuff is in IntelliSenseServer. |
Last update didn't change the binaries, I think. |
Yes it works today, as long as the latest version is loaded first in the AppDomain (which is usually the case in the happy path), although it doesn't hurt to reference the updated one. Having said that, once we release the signed version of |
Thanks. I found it and updated the PR to bump it. |
@@ -30,7 +30,7 @@ namespace ExcelDna.IntelliSense | |||
// REMEMBER: COM events are not necessarily safe macro contexts. | |||
public static class IntelliSenseServer | |||
{ | |||
const string ServerVersion = "1.0.10"; // TODO: Define and manage this somewhere else | |||
const string ServerVersion = "1.2.0"; // TODO: Define and manage this somewhere else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why so high? Maybe 1.1.0 for the next version (and 1.1.1 etc. for small updates during the 1.1.0 ExcelDna.Integration life?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the ServerVersion and the AssemblyVersion can be kept in sync in the strong-name world? Then we might as well keep the assembly version fixed at 1.1? (or 1.1.1). I'm getting confused...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why so high? Maybe 1.1.0 for the next version (and 1.1.1 etc. for small updates during the 1.1.0 ExcelDna.Integration life?)
AssemblyVersion
is 1.1.0
already. It seems this ServerVersion
variable went out of sync with the AssemblyVersion
. So in this PR I'm bumping the AssemblyVersion
to 1.2.0
and keeping ServerVersion
in sync...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the ServerVersion and the AssemblyVersion can be kept in sync in the strong-name world? Then we might as well keep the assembly version fixed at 1.1? (or 1.1.1). I'm getting confused...
I'd suggest we sync ServerVersion
with AssemblyInformationalVersion
(which is what gets translated to ProductVersion
at the end.
The reason being that any modern build servers (such as Azure Pipelines) supports updating the AssemblyInformationalVersion
during build and baking it into the compiled assembly... And to make ServerVersion
get bumped it would take some scripting.
If I understand correctly, ServerVersion
is just a custom metadata that is used to determine the highest version of the IntelliSense from all the available IntelliSense servers across all add-ins, so the number doesn't really matter much, as long as it's always higher than the previous release.
... as the title says