Internals class and method

Mar 2, 2016 at 11:35 AM
I beg you to make public all the internal methods and classes.
Otherwise, I have to edit the source code or completely copied.
Example:
I need additional arguments for WixSharp.CommonTasks.Tasks.InstallService (user and password).
I wanted to create a task, but class ExternalTool is internal.
Or I wanted to create a WixPathEdit base from WixTextBox.
Mar 3, 2016 at 1:41 AM
You would probably agree that making all types and their members unconditionally public is not exactly a reasonable approach.
I do agree that excessive 'hiding' is one of the biggest problems in API design and I am more than happy to address any issues if found. Thus please let me know what exact problems you are having.

> I need additional arguments for WixSharp.CommonTasks.Tasks.InstallService (user and password).
This one has nothing to do with the visibility as it's already public. Though extra argument just has been added. Will be available in the next release.

> I wanted to create a task, but class ExternalTool is internal.
ExternalTool was design specifically for the internal use of WixSharp and I didn't feel as it its implementation meets the standards of the public API. Though after reviewing it again I decided to make it public as you asked. Will be available in the next release.

> Or I wanted to create a WixPathEdit base from WixTextBox
This one has nothing to do with the visibility as WixTextBox and all its members are already public.
As a side comment, you probably remember that I have already indicated that MSI native UI support is discontinued so any work with the corresponding types (e.g. WixTextBox) may attract some obvious risks/limitations. The currently preferred/supported alternative technique is EmbeddedUI.
Mar 4, 2016 at 9:17 AM
Я бы это регулировал namespace. Есть открытые namespace, такие как CommonTask и др. Они поддерживаются и могут безопасно использоваться. А есть закрытые CommonTask.Internal, которые каждый может использовать, но на свой страх и риск, за последствия их применения никто не может нести ответственность. Если это суперпрограммист, который разбирается во всем и хочет программировать в режиме ядра, то пусть программирует: создает свой проект и вперед. Потом он может передать весь проект автору, а не тыкать его в каждый файл с нужными правками.
Это мое мнение, а не побуждение к действию :)

По поводу WixTextBox я хотел бы пояснить, что я имел ввиду. Там есть метод:
 public virtual Wix.Controls.Control ToWControl()
        {
            Wix.Controls.Control control = this.ConvertToWControl(ControlType.Edit);

            if (BoundProperty.IsEmpty())
                throw new ApplicationException("WixTextBox ('" + control.Id + "') must have BoundProperty set to non-empty value.");

            return control;
        }
я хотел поменять ControlType.Edit на ControlType.PathEdit, но ConvertToWControl - internal. Ну нет, так нет. Я забил на это. :)
Mar 5, 2016 at 1:41 AM
> ...я хотел поменять ControlType.Edit на ControlType.PathEdit, но ConvertToWControl - internal...
This is exactly what I was looking for.
You are right there is no any good justification for for ConvertToWControl to be hidden. In fact it is wrong as this method is for external consumption. Fixed and will be available in the next release.

> Потом он может передать весь проект автору, а не тыкать его в каждый файл с нужными правками.
You don't have to.

Just fork your branch and work in it as it is your own. When and if you feel that your work can be beneficial for others then juts push it to repo and send the pull request to the project coordinator (me). That is it.