根据 MSI 文件名更改 Windows 应用程序的 GUI
我们正在使用 C# 开发 Windows 应用程序。我们想根据品牌名称更改 GUI(背景图像和其他控制图像和文本)。
应用程序的典型安装程序的名称为 brandname_programname.msi
。我们必须从 MSI 获取品牌名称并据此分配 GUI。请注意,除了 MSI 中的不同品牌名称之外,我们不会传递任何其他对象、设置来指示差异。我们怎样才能达到这个结果呢?
我们不需要 WPF 解决方案。
We are developing a Windows application using C#. We would like to change the GUI (background images and other control images and text) based on brandname.
The typical installer of the application will be having the name brandname_programname.msi
. We have to take the brandname from the MSI and allocate the GUI based on that. Please note we are not passing any other objects, settings to indicate the differences other than different brandnames in the MSI. How can we achieve this result?
We don’t want a WPF solution please.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您的描述让我相信您在所有安装中发送了整个品牌图像和文本集合,然后通过更改您想要过滤的 gui 元素的 msi 文件的名称。
我发现这是一个非常不稳定的解决方案,因为您完全依赖管理员而不重命名 msi 文件 - 例如,如果管理员将名称从“CompanyA_programname.msi”更改为“programname.msi”,会发生什么情况,证明该决定是合理的“文件名中包含我们的名字是没有用的——我们只有这个。”
此外,许多客户不希望与竞争对手分享他们的品牌元素 - 因此在 msi 中包含所有品牌图像可能会与您的客户协议相冲突。
在我看来,您应该从其他方式解决这个问题 - 要么为每个品牌构建一个单独的 msi 文件,要么只构建单一类型的 msi 并强制安装环境以文件夹或 zip 文件的形式提供 gui 元素。然后使用这些元素来填充 GUI,无论公司如何。
诚然,文件夹/zip 方法仍然不稳定,您必须处理没有此类文件的情况,但仍然不存在单点故障。
根据我之前的经验,我强烈建议您为每个品牌构建单独的 msi 文件。通过这种方式,您可以最大限度地减少因误用而导致失败的风险或恶意行为的风险。
Your description leads me to believe that you're sending the entire collection of brand images and text in all installations, and then by changing the name of the msi file you want to filter the gui elements.
I find this a very volatile solution, since you rely completely on your admins not renaming the msi file - what will happen for instance if an admin changes the name from "CompanyA_programname.msi" to just "programname.msi", justifying the decision with "There is no use in having our name in the file name - we only have this one."
Furthermore, many customers do not wish to share their brand elements with the competition - so including all brand images in the msi would potentially be in conflict with your customer agreement.
In my opinion, you should approach the issue from the other way - either build a separate msi file for each brand, or just build a single type of msi and force the installation environment to supply the gui elements as a folder or a zip file. Then use those elements to populate the gui regardless of company.
Granted, the folder/zip approach is still volatile and you have to handle the case when there are no such files, but there is still not that single point of failure.
Based on my previous experience, I would strongly suggest that you build a separate msi file for each brand. This way you minimize the risk of failure caused by misuse, or the risk of malignant actions.