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

Review and consolidate migrated registration code #739

Open
govert opened this issue Dec 5, 2024 · 1 comment
Open

Review and consolidate migrated registration code #739

govert opened this issue Dec 5, 2024 · 1 comment
Assignees

Comments

@govert
Copy link
Member

govert commented Dec 5, 2024

To support improved 'extended registration' by default, we've duplicated much of the code from ExcelDna.Registration into ExcelDna.Integration. We would like to remove and deprecate ExcelDna.Registration.

  • Currently helper methods in the registration pipeline like ProcessParamsRegistrations are marked internal. This means an add-in cannot define an 'explicit registration' approach which uses these helpers.
  • We should make those methods that match the public interface of ExcelDna.Registration also public from ExcelDna.Integration, and in the same namespace as before.
  • This should mean we can recompile examples like https://github.com/Excel-DNA/Samples/tree/master/Registration.Sample by just removing the ExcelDna.Registration package.

Finally, we should remove the code from ExcelDna.Registration and mark the package as Deprecated.

@govert
Copy link
Member Author

govert commented Dec 12, 2024

One option would be to make a new set of public types inside ExcelDna.Integration that has the same namespace and names as the types in ExcelDna.Registration, but forwards the work to the types in ExtendedRegistration.
Another option is to rename and make public the corresponding types, to make them compatible with code that would have used ExcelDna.Registration before.

I think we should be able to move everything from ExcelDna.Registration and ExcelDna.Registration.VisualBasic into the main ExcelDna.Integration library.

For ExcelDna.Registration.FSharp, we should make and example with whatever the smallest snippet of code is that a user can add to their project to support the FSharp async type. We can put this inside the Registration.FSharp sample in the Samples repository. Maybe just this code as is: https://github.com/Excel-DNA/Registration/blob/master/Source/ExcelDna.Registration.FSharp/FsAsyncUtil.fs

The end result should we:

  • Code that used ExcelDna.Registration.* should now compile and work without a package reference to ExcelDna.Registration. (With the exception of the F# addition, where an extra piece of code is needed in the user project).
  • We deprecate the ExcelDna.Registration packages.
  • Fix the Registration.* samples in the Samples repo (once we have the pre-release packages with the above changes).

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

No branches or pull requests

2 participants