Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Preventing Port/Application Change in the event of an upgrade
miro
#1 Posted : Monday, February 11, 2008 6:00:34 PM(UTC)
Groups: Member
Joined: 11/17/2007(UTC)
Posts: 4
Location: US

Is there a way to prevent the custom setup action from overwriting an existing application entry?

I am noticing that if I install a new version of my product on top of an existing version, then the assigned port gets changed as if the application is a new instance.

Because my users may have to manage XP or other personal firewall software, I would like to prevent updates from changing the port.

I do like the randomization of the initial port assignment, but I also allow the end user to set their own preferred port, and I would like to retain that setting if possible.

Thanks in advance... great product!
Ultidev Team
#2 Posted : Monday, February 11, 2008 7:18:54 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi!

Thank you for using UltiDev Cassini and for your positive feedback!

Windows firewall should not be a problem because when UltiDev Cassini gets installed, it creates Windows Firewall exceptions for itself. Other personal firewalls, however, are not supported.

If you still have to make sure that subsequent versions of your application are using the same port, then the bad news - current implementation of the Cassini Configuration API does not save previous application's port number on its own, but we are going to change this in the future version.

The good news - there is a possible workaround, although it will require a little bit of programming on your part. To keep the same port between installations of the version 1.0 ad 2.0 of your application you could do this:

- In version 1.0 implement Commit custom installer step (using Installer class) to retrieve and store (for example, in the Registry) the port number your application was assigned. To retrieve your application port number you would use Metabase.Load() method to get the instance of the Metabase object, and then call FindApplication() method, to get access to the ApplicationEntry structure defining your application registration parameters, one of which is the port number. You could save port number value in the Registry or some place else for the version 2.0 of your application to pick it up.

- Version 2.0 of your application then would have to implement Install custom step, where it would retrieve the port number from the Registry, or wherever it was stored by the version 1.0, and then use Metabase.IsPortFree() and Metabase.RegisterApplication() methods to register the application manually with the same port number it had before.

Next version of Cassini Web Server will have Cassini Configuration API saving port number of uninstalled applications for subsequent use during the installation, so you would not have to go through the trouble.

Please let us know if this information has helped.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
miro
#3 Posted : Tuesday, February 12, 2008 4:04:22 AM(UTC)
Groups: Member
Joined: 11/17/2007(UTC)
Posts: 4
Location: US

Thanks for the fast response... this sounds very doable.

When you say UtliDev makes exceptions for itself in Windows Firewal, do you mean that if register an application at port 4848, then port 4848 is opened through the firewall? Just curious, that would actually save me some programming steps.
Ultidev Team
#4 Posted : Tuesday, February 12, 2008 4:35:26 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi!

Windows Firewall exceptions can be created not only per-port, but also per-process. We used the latter, which allowed UltiDev Cassini Web Server process to listen on any port. If you bring up Windows Firewall properties on a machine where UltiDev Cassini Web Server is installed, you will see how exceptions settings are applied.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Ultidev Team
#5 Posted : Tuesday, February 12, 2008 5:20:58 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
One more thing that every Visual Studio setup project developer must be aware of is this:
Assemblies that contain your custom installer steps need to be signed and/or have different name between versions of your application.
The reason for that is that due to a pretty horrible (in our opinion) design decision on how assembly loading logic is implemented in .NET Framework, old version's custom steps may be called not only to do Uninstall, but also Install and Commit, meaning that new version's Install steps will not be called. More details on this can be found here.

Besat regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Rss Feed  Atom Feed
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You can vote in polls in this forum.