Лучший способ, который я нашел, - это написать модульный тест, а также обновить и инициализировать ваш класс установщика из вашего модульного теста:
[TestClass] public class InstallerTest {
[TestMethod]
public void InstallTest() {
// substitute with your installer component here
DataWarehouseInstall installer = new DataWarehouseInstall();
string assemblyDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string installLogFilePath = Path.Combine(assemblyDirectory, "install.log");
installer.Context = new System.Configuration.Install.InstallContext(installLogFilePath, null);
// Refactor to set any parameters for your installer here
installer.Context.Parameters.Add("Server", ".");
//installer.Context.Parameters.Add("User", "");
//installer.Context.Parameters.Add("Password", "");
installer.Context.Parameters.Add("DatabaseName", "MyDatabaseInstallMsiTest");
//installer.Context.Parameters.Add("DatabasePath", "");
// Our test isn't injecting any save state so we give a default instance for the stateSaver
installer.Install(new Hashtable());
} }
По крайней мере, тогда он лучше использует инструменты IDE. Это особенно полезно для очень больших инсталляторов с большим количеством компонентов. Затем вы также можете создавать заказанные модульные тесты и запускать их последовательно, чтобы имитировать ваш установщик во время отладки или ваших автоматических сборок.
Другим советом могут быть общие принципы программного обеспечения SOLID / GRASS ... развиваться аккуратно и тонко, сохраняя простую логику вашей программы установки "настраиваемых действий", и вместо этого вызывайте любые имеющиеся у вас многократно используемые API-интерфейсы, специфичные для вашего установщика (s), как мы привыкли к разработке пользовательского интерфейса. (В любом случае, установщик - это просто еще один пользовательский интерфейс.) Это особенно важно, если ваша цель состоит в том, чтобы использовать определенный интерфейс пользовательского интерфейса для всех установщиков ваших продуктов.