By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,289 Members | 1,337 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,289 IT Pros & Developers. It's quick & easy.

Custom controls deployment woes...Terminal Services

P: n/a
My department is responsible for creating custom internal applications for
many of our departments. Our strategy has always been to develop our
applications as ActiveX controls (VB6) that get hosted in Internet Explorer.
I've been tasked with coming up with a strategy for our migration to using
VB.Net. So far, I've experienced a number of items that caused us a few
stalls, but mostly was able to resolve them after some thinking and
experimenting with the .Net Framework. Right now we have hit a critical
stumbling block in our development test for VB.Net.

We develop our application as ActiveX controls since it make for easier
deployment of our applications. When an update is available for the
application, it is automatically downloaded to the users's machine and
installed through Active Directory Group Policies (user is member or Users
group and we are publishing the ActiveX Controls in Active Directory -
Q280579 & Q241163). Our users also make extensive use of Terminal Services
(some users access the application remotely from overseas via a slow link)
and the controls are updated on the Servers on a set schedule by our
Administrators.

We want to continue using the Internet Explorer hosting model for our
applications since distribution is very easy and our users are confortable
with this way of working.

I've found that we can create Windows Forms controls which behave similarly
to ActiveX controls in the browser. I've also found that distribution of
the controls to the user's machines is actually easier since I only have to
publich the .Net Security Policy to trust the strong name of the assembly in
question (FullTrust). The users can goto the URL and download the assembly
and continue working without any problem.

The problem is this model won't work for Terminal Services users. The only
way .Net controls show up in IE on the Terminal Servers is when I log in
with a priveleged account (member of the Administrators group). Is there
some configuration that I am missing with Terminal Server or the .Net
Framework when using Terminal Server?

We'd like to not have to change our application model as we have many
applications that run in this model and some of them interact with the other
controls via page event handling in the browser. If we were to have to
change to a different application model, would Terminal Services be able to
handle automatic updates through the application updater block?

Thanks.
Nov 20 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.