Skip to content
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

Merged

Conversation

augustoproiete
Copy link
Member

... as the title says

@augustoproiete augustoproiete self-assigned this Nov 7, 2019
@augustoproiete augustoproiete requested a review from govert November 7, 2019 05:23
@govert
Copy link
Member

govert commented Nov 7, 2019

So my thought would be - why? I guess in Registration that didn't occur because the version number was old there.
The reason, I guess, us to get the signed ExcelDna.Intrgration? If so, that's OK. But I would in future like to keep the releases of IntelliSense and the core add-in independent where it makes sense.

@govert
Copy link
Member

govert commented Nov 7, 2019

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.

@augustoproiete
Copy link
Member Author

So my thought would be - why?

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 ExcelDna.Integration.dll.

If the above is true, then I'd expect an updated release of ExcelDna.IntelliSense every time a new ExcelDna.Integration gets released - side-by-side.


Once the signed version of ExcelDna.Integration is released as a nuget package, then we can update this again (future PR) to reference the new NuGet package (1.1.0) and then sign ExcelDna.IntelliSense in the process.

@augustoproiete
Copy link
Member Author

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.

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 1.0.9 to 1.1.0 and didn't see anything special other than updating the assembly version and nuspec.

@govert
Copy link
Member

govert commented Nov 7, 2019

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.

@govert
Copy link
Member

govert commented Nov 7, 2019

Last update didn't change the binaries, I think.

@augustoproiete
Copy link
Member Author

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.

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 ExcelDna.Integration (1.1.0), then we do need re-target ExcelDna.IntelliSense to reference & depend on that version. After that, it's back to normal and we can choose not to keep it in sync (as it is today).

@augustoproiete
Copy link
Member Author

Version stuff is in IntelliSenseServer.

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
Copy link
Member

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?)

Copy link
Member

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...

Copy link
Member Author

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...

Copy link
Member Author

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.

@govert govert merged commit fe00169 into Excel-DNA:master Nov 7, 2019
@augustoproiete augustoproiete deleted the target-exceldna-v1.0.0 branch November 7, 2019 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants