I have a question regarding to Setup Projects in .Net (c# language, Framework 4.0):
I made a setup project for a Windows Service, on the installation wizard, the user must input the name of the Windows Service as it would be installed. The setup program also creates a shortcut to the Uninstall program in case the user wants to remove that Windows Service.
The question is: how to let the user run the same setup program several times specifing different service name?
This behaviour could be required because the windows service is a socket consumer that connects to a server and retrieves data; to take advantage of the server capabilities the user could install the same windows service multiple times pointing to a different port on the server, to perform the data retrieving task much faster. The service is the same, the user just modify the port on the configuration file of the service, so that's why it's not logical to create a new version of the installer each time.
Any clue or suggestion would be appreciated, thanks in advance.
This can be done by using an multiple instances installation. The general approach is:
create a transform for each instance you want available to the user
use a custom EXE bootstrapper which applies a new transform to your MSI package each time a new instance is installed
The transform should change at least the PackageCode, ProductCode and UpgradeCode.
This is not supported by Visual Studio setup projects. So either you do it manually or use a commercial setup authoring tool which supports multiple instances.
Related
Is it possible to deploy installers (for example Chrome browser .exe file) to install on Windows client computers across all office buildings using OpenLDAP? The OpenLDAP is installed on CentOS 8. If it is not possible can Active Directory Help Me?
Why would you use a directory service to store binary files? This might be possible but it's a terrible idea.
Active Directory is a broad suite of tools. AD Domain Services is basically the OpenLDAP equivalent https://social.technet.microsoft.com/wiki/contents/articles/699.active-directory-domain-services-ad-ds-overview.aspx and doesn't do what you want
AD GP (Group Policy) allows you to push software https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software but if you're only using it to push a Chrome installer, it's overkill to set it all up. It does work though!
You can also use SCCM (oh I guess it's called MECM now, haven't touched it in a hot minute).
I am currently working to move TFS from its' current server to a new environment. My team has already completed the steps as seen in this Microsoft Documentation on moving TFS to a new Server.
We have already installed and migrated/restored our SQL Database in the new server and ensured all the prerequisites for TFS were installed. The TFS Admin Console is currently installed and we are trying to configure it by using the existing Tfs_Configure database. That all works without a problem, however, when we go to look at our existing Project Collections, the build service is still "linked", having the TFS Address set to the old server and not the one we migrated to.
I have detached the collections in the old environment and reattached them in the new environment, however, they still seem to be trying to build in the old server. I am reading that we needed to detach them prior to migrating any data over. Did we do something incorrectly, or rather, did we try to detach the collections too late into the process?
You need to unregister the build service that uses the <<oldcomputername>>. Register a build service with the <<newcomputername>>. And do the same for the agent and the controller.
On each build server, open the administration console and stop the
build service.
In the properties for the build service, update the communications
properties.
According to the above screenshot, you could see the build service is configured under project collection level.
Moreover, for vNext build agent you need to remove and re-configure an agent.
To remove the agent:
.\config remove
After you've removed the agent, you can configure it again.
You have to update your build services to point to the new server. For XAML build, you'll have to reconfigure the build controller. For the modern build system, you'll need to reconfigure your build agent(s).
I have an app which needs to be installed for all the services I have. Unfortunately, installation requires many files and task related input parameters (e.g. RoleInstanceValue xpath=...).
The way I came up with to share this task among cloud service projects is through Azure Plugins (here is a link to a library of them http://richorama.github.io/AzurePluginLibrary/).
The problems I see with this approach are:
It is not recommended/supported by Microsoft, which means they can
change support for that any time.
It requires copying files to C:\Program Files\Microsoft
SDKs\Azure\.NET SDK\v2.6\bin\plugins\NxlogAzureForwarder, adding an
extra step to build setup.
Microsoft recommends startup tasks. But I could not figure out a way to share them among cloud services.
So, my question is: how to easily reuse startup tasks?
As recommended your best chance would be a startup task that starts your app, which would be encapsulated into a Windows service. That service is going to be your reusable task/app/service (whatever you call it).
What you need extra is the following:
Project reference to your Windows service
An install script for the service
Installer tool
(Optional) app config for your service
To start your app/service you need to update cloud service definition by adding start up task and making runtime context elevated, and start your service in OnStart entry point.
That being said, you can place parameters of your app in the cloud config and read them in your WebRole and pass them to your service.
For more detail check out this post.
Is it possible to deploy a windows service without going through Installshield? I have a very basic service which simply probes a database, and wish to deploy it on a server.
I tried using Installsheild LE, but get error 1001 on install, which is hard to troubleshoot, and anyhow Installshield feels like overkill in this case... is there a way can just install the service direct by command line or other method?
Yes.
However, there are options, from best to worst:
There are other tools for writing installers out there. Eg. the full version of install Shield or WiX (which MS created, and is used for the Visual Studio installer).
You could use installUtil having included a type derived from ServiceInstaller in your assembly. (See How to: Install and Uninstall Service.)
You can manually edit the registry.
#3 Is seriously easy to mess up, and won't help you with the event logging and performance counters you should be including.1 #2 is best in development, and will set up event logs and performance counters as well (remember you'll need to elevate to install things, and to attach a debugger to the service when running as a service).
Using a real installer (#1) is best in test (staging) and production environments.
1 When you get asked why it isn't working, you'll want to be able to work out what's going on (or not).
Yes, if your service has an Installer class then, you can install it from command line with installutil.exe
using System.ComponentModel;
using System.Configuration.Install;
using System.ServiceProcess;
[RunInstaller(true)]
public class ServiceInstaller : Installer
{
public ServiceInstaller()
{
ServiceProcessInstaller serviceProcessInstaller = new ServiceProcessInstaller();
ServiceInstaller serviceInstaller = new ServiceInstaller();
//# Service Account Information
serviceProcessInstaller.Account = ServiceAccount.User;
serviceProcessInstaller.Username = "";
serviceProcessInstaller.Password = "";
//# Service Information
serviceInstaller.DisplayName = "Service name"
serviceInstaller.Description = "Service description"
serviceInstaller.StartType = ServiceStartMode.Automatic;
//# This must be identical to the WindowsService.ServiceBase name
//# set in the constructor of WindowsService.cs
serviceInstaller.ServiceName = "Service Name";
this.Installers.Add(serviceProcessInstaller);
this.Installers.Add(serviceInstaller);
}
}
Building and Deploying a Windows Service using IsWiX
The above is a short video I made showing how to use WiX / IsWiX to generate a very clean MSI for installing a service. It's really easy, fast, elegant and free.
You can use the command line tool sc.exe to create and configure a windows service (basically insert the config into registry), assuming you have already deployed the built .exe to disk somewhere on your server.
http://support2.microsoft.com/kb/251192
I am seeking advice: Ideally, I would like to give an Administrator (of the web server) one file (.exe, .msi, .bat, whatever you suggest), so that when they execute the package, it will setup my application (contains .aspx, .xap silverlight, web service .svc, etc.) on IIS. This will include and certainly not be limited to such things in the IIS Manager, like creating a virtual directory, path, default document, security, and all of the IIS settings one finds via inetmgr and properties. I would also maybe like to run a .bat file (not sure if this correct), but to check for certain settings and pinging other servers for status.
Many years ago, I used to automate everything and used concepts like .bat files - got the job done and it was amazing what I could do. Fast forward a couple of years now and am approaching the automation process again. I wanted to know if there is anything new out there.
Any and all advice will be greatly appreciated!
It's quite a bit of a learning curve but yes, WiX / InstallShield / MSI can do this. I've done installers for n-Tier / SOA systems including single tenant SaaS where you could run the application layer installer dozens of times creating new instances running on different host headers or ports pointed to different data layers and different configuration settings. You could then do the same for the WebUI pointing to which ever application layer you want.
Basically whether it's instaling .NET, setting up vDir / AppPools / WebSites / Extensions, reading and writing XML config files, executing SQL scripts, creating services and so on it can all be done... if you take the time to learn it all. Deployment Engineering is a bigger domain then it first appears to be.
As for .BAT, that's bad form. First you work to leverage native capabilities before writing custom actions. Then when you do have to write one, you design it to be declarative and transactional ( install, uninstall, rollback, commit ). WiX has a really nice framework called DTF that allows you to encapsulate C# classes as if they were C++ from MSI's perspective and provides a nice interop library needed to talk to MSI during the install.
Visual Studio has a Web Setup Package project you can use for this.