Quantcast
Channel: wixsharp Discussions Rss Feed
Viewing all articles
Browse latest Browse all 1354

New Post: Internals class and method

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

Viewing all articles
Browse latest Browse all 1354

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>