Does not run our app on Windows Vista

[Guest]

When there is a shortcut of our app on the desctop, the app is not run until
all the security in control panel of win vista is cleared. What to do to not
have this problem. We do not want to tell the customers to do this.

 

[Mr. Arnold]

When there is a shortcut of our app on the desctop, the app is not run
until
all the security in control panel of win vista is cleared. What to do to
not
have this problem. We do not want to tell the customers to do this.

You need to explain this better. What do you mean the security in Control
Panel is cleared? What does the Control Panel have to do with the running
of some program that has a Short=cut sitting on the Vista desktop?

 

[Guest]

When double clicking the windows the app starts, but before the app finishes
loading it exits. This happends on Vista only. One our support team changed
Vista security and it worked. But this is not a good solution for all
customers.

 

[Mark Rae [MVP]]

When double clicking the windows the app starts, but before the app
finishes
loading it exits. This happends on Vista only. One our support team
changed
Vista security and it worked. But this is not a good solution for all
customers.

Vista is very different from earlier versions of Windows, especially with
respect to security, folder structure, Registry access etc.

What happens when your developers run the app in VS.NET 2005 on Vista and
step through the startup routine...?

 

[Kevin Spencer]

Hi Mike,

Add a manifest to the assembly. See
http://blogs.msdn.com/shawnfa/archive/2006/04/06/568563.aspx

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Mr. Arnold]

When double clicking the windows the app starts, but before the app
finishes
loading it exits. This happends on Vista only. One our support team
changed
Vista security and it worked. But this is not a good solution for all
customers.

You may need to post to MS.Public.Windows.Vista.Security or General NG.

I'll assume you are aware of the Vista UAC Manifest that a program may need
to use to present security credentials to Vista.

There could also be a .NET application trust issue that can exist on the
client machine, and .NET could be stopping the program from running.

You might want to look into something like Caspol.exe to set a program's
..Net security policy for an application via an install package on the
client's computer.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

When there is a shortcut of our app on the desctop, the app is not run
until
all the security in control panel of win vista is cleared. What to do to
not
have this problem. We do not want to tell the customers to do this.

you need to provide more details, I have recently deployed an app in vista
and had no such a problem (I had several others though).

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

When double clicking the windows the app starts, but before the app
finishes
loading it exits. This happends on Vista only. One our support team
changed
Vista security and it worked. But this is not a good solution for all
customers.

Believe it or not sometimes there is nothig else you can do. I got this
problem firsthand. I've an application that integrate with QuickBooks, well
it only works if UAC is active. Otherwise it fails.

The same application has a windows service that access the network and start
with the system. Well the only way you can install it is with UAC turned
off. , otherwise it fails.


AFAIK there is nothing you can do to avoid escenarios like the above. Except
maybe running XP

 

[Guest]

No, I was not aware of UAC in Vista. Will embeding this manifest affect the
app running in XP?

 

[Mark Rae [MVP]]

No, I was not aware of UAC in Vista.

In which case, you really need to build a machine (a virtual machine will be
fine) and install Vista, then Visual Studio.NET 2005, then SP1, then the
Vista Update Patch and run your app in that environment to see what it is
doing.

You simply *cannot* assume that any app developed under XP will run
unmodified on Vista. Most will, but some will not - you just can't make the
assumption that yours will... This is especially true if your app writes to
the Registry, or needs write access to any of the folders which have more
restricted privileges in Vista...

Even some of the major app vendors (e.g. Adobe) struggled to get
Vista-compliant versions of their apps to market...

 

[Mr. Arnold]

No, I was not aware of UAC in Vista. Will embeding this manifest affect
the
app running in XP?
--

My rule of them is software developed, tested and deployed on the platform
it is intended to run on.

A solution developed, tested and on the Vista platform to be deployed to
the Vista platform.

A solution developed, tested and on the XP platform to be deployed to the XP
platform.

The reason you do this is to avoid components such as a DLL that maybe
common to both platforms in its naming convention but can be specific to a
given platform, which will replace like named DLL on another platform.

A DLL can be specific to the given platform, and it can break other
solutions running on another platform that is depended upon the DLL, but the
DLL belongs to another platform.

There is no guarantee that a solution that was built on one platform is
going to run on another platform. And this type of deployment situation
should be avoided.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

My rule of them is software developed, tested and deployed on the
platform it is intended to run on.

A solution developed, tested and on the Vista platform to be deployed to
the Vista platform.

A solution developed, tested and on the XP platform to be deployed to the
XP platform.

The reason you do this is to avoid components such as a DLL that maybe
common to both platforms in its naming convention but can be specific to a
given platform, which will replace like named DLL on another platform.

A DLL can be specific to the given platform, and it can break other
solutions running on another platform that is depended upon the DLL, but
the DLL belongs to another platform.

There is no guarantee that a solution that was built on one platform is
going to run on another platform. And this type of deployment situation
should be avoided.

Sometimes you cannot control that, and honestly the expectation from most of
the users is that any app that runs in XP should run in Vista (which is not
true)

 

[Guest]

My rule of them is software developed, tested and deployed on the
platform it is intended to run on.

A solution developed, tested and on the Vista platform to be deployed
to the Vista platform.

A solution developed, tested and on the XP platform to be deployed to
the XP platform.

The reason you do this is to avoid components such as a DLL that maybe
common to both platforms in its naming convention but can be specific to
a given platform, which will replace like named DLL on another platform.

A DLL can be specific to the given platform, and it can break other
solutions running on another platform that is depended upon the DLL, but
the DLL belongs to another platform.

There is no guarantee that a solution that was built on one platform is
going to run on another platform. And this type of deployment situation
should be avoided.

Good if it is possible.

But the reality is often more gray.

XP no SP, XP SP1, XP SP2, 2003 no SP, 2003 SP1, Vista = 6 possible
let us say 20 relevant languages
IE6, IE7 = 2 possible

That is 240 combinations. Not many will test everything.

Then add 32 bit/64 bit, .NET versions, Office versions,
SQLServer none/2000/2005 and it becomes impossible to test.

Arne

 

[Mark Rae [MVP]]

Good if it is possible.

But the reality is often more gray.

XP no SP, XP SP1, XP SP2, 2003 no SP, 2003 SP1, Vista = 6 possible

Not quite...

If you are writing a WinForms app, then you would logically expect your
users to be using the latest service pack i.e. WinXP + SP2 - same for 64-bit
XP... Many, many apps will tell you at installation time that they require
SP2 of XP - nothing wrong with that...

The various versions of Vista don't work differently one from another - they
simply include more or less features - so pick the "lowest" one which your
app can support and test on that - 32-bit and 64-bit, obviously...

Windows 2003 is a server, not isn't a desktop platform, so put a warning
message in your startup saying that your app isn't designed to be run on
that platform or, better still, prevent it from even being installed on that
platform...

So that makes four versions of Windows: 32-bit WinXP + SP2, 64-bit WinXP +
SP2, 32-bit Vista & 64-bit Vista

As and when Microsoft bring out later service packs, then you will need to
test your app on them and, if necessary, issue a patch - this was especially
true when SP2 for XP was released, as it even stopped some of Microsoft's
own apps from working. Again, nothing you can do about that...

let us say 20 relevant languages

If your app supports globalisation, then you *will* have to test it on
various languages - that's just the way it is... If you don't need
globalisation, then you don't... Put a warning in the setup and/or
installation which says that your app is not designed to be run on this or
that language version of Windows...

IE6, IE7 = 2 possible

If we're talking about WebForms, then you will need to test on many more
browsers than that, and not just on the Windows platform...

.NET versions

WinForms apps are compiled for one particular version of the .NET
Framework - the setup will make sure that that version is installed...

Office versions,

Again, if your app interfaces with Office, you *will* need to test against
all the versions which it is designed to support...

and it becomes impossible to test.

If you really believe that, then you're in the wrong business...

 

[Guest]

Not quite...

If you are writing a WinForms app, then you would logically expect your
users to be using the latest service pack i.e. WinXP + SP2 - same for
64-bit XP... Many, many apps will tell you at installation time that
they require SP2 of XP - nothing wrong with that...

The various versions of Vista don't work differently one from another -
they simply include more or less features - so pick the "lowest" one
which your app can support and test on that - 32-bit and 64-bit,
obviously...

Windows 2003 is a server, not isn't a desktop platform, so put a warning
message in your startup saying that your app isn't designed to be run on
that platform or, better still, prevent it from even being installed on
that platform...

So that makes four versions of Windows: 32-bit WinXP + SP2, 64-bit WinXP
+ SP2, 32-bit Vista & 64-bit Vista

I am not sure everybody will consider i commercially feasible to not
support XP SP1 because it is too old and 2003 because it is a server OS.

MS choose f.ex. to deliver the VS 2008 CTP's/Beta's on virtual images
with 2003.

If your app supports globalisation, then you *will* have to test it on
various languages - that's just the way it is... If you don't need
globalisation, then you don't... Put a warning in the setup and/or
installation which says that your app is not designed to be run on this
or that language version of Windows...

Even if your app does not intend to support i18n, then it may still
malfunction on non english versions (for reasons unknown to me MS has
choosen to internationalize directory names).

If we're talking about WebForms, then you will need to test on many more
browsers than that, and not just on the Windows platform...

I am still talking about win forms.

I learned the hard way many years that an IE installation actually
upgraded ODBC on a system.

(not obvious why, but it did)

If you really believe that, then you're in the wrong business...

Anyone who think it is easy to test all possible setups for
desktop apps are in the wrong business.

Arne

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I am not sure everybody will consider i commercially feasible to not
support XP SP1 because it is too old and 2003 because it is a server OS.

MS choose f.ex. to deliver the VS 2008 CTP's/Beta's on virtual images
with 2003.


Even if your app does not intend to support i18n, then it may still
malfunction on non english versions (for reasons unknown to me MS has
choosen to internationalize directory names).


I am still talking about win forms.

I learned the hard way many years that an IE installation actually
upgraded ODBC on a system.

(not obvious why, but it did)


Anyone who think it is easy to test all possible setups for
desktop apps are in the wrong business.

Hear that. And with Vista you have to add the possibility of having UAC
on/off

 

[Mr. Arnold]

Good if it is possible.

It's always going to be possible with me. That's the way I work. And that's
what I have been taught. I am never ever ever going to create such a
situation or solution that's built on one platform to be deployed to another
platform.

It maybe good if possible for you. But I hold myself to a higher standard.

 

[Mr. Arnold]

Sometimes you cannot control that, and honestly the expectation from most
of the users is that any app that runs in XP should run in Vista (which is
not true)

All you have to do is go to MS.Public.Windows.Vista.General and see posts
about a user installing non Vista compliant software that's a XP solution,
as an example, on the Vista machine and watch the software not work or break
other Vista compliant solutions or even start crashing the Vista O/S. Or
they upgrade over the top the machine using the XP O/S and software with
Vista, and that causes problems as well.

They can't seem to put 2 and 2 together and understand that the non Vista
compliant software that was installed is causing all kind of problems.

My rule of thumb and the way I keep myself out of trouble in using Vista is
not one bit or byte from a non Vista compatible solution touches the Vista
machine. If it's not a a Vista compliant solution from a vendor with some
software I am using, then I'll find an alterative or I'll wait until the
vendor has a Vista compliant solution.

http://www.bestvistadownloads.com/

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

It's always going to be possible with me. That's the way I work. And
that's what I have been taught. I am never ever ever going to create such
a situation or solution that's built on one platform to be deployed to
another platform.

It maybe good if possible for you. But I hold myself to a higher standard.

Well, it seems that you live in a more perfect world that we do

I have to make my app to run in 2K, XP and now Vista.

 

[Ignacio Machin \( .NET/ C# MVP \)]

All you have to do is go to MS.Public.Windows.Vista.General and see posts
about a user installing non Vista compliant software that's a XP solution,
as an example, on the Vista machine and watch the software not work or
break other Vista compliant solutions or even start crashing the Vista
O/S. Or they upgrade over the top the machine using the XP O/S and
software with Vista, and that causes problems as well.

They can't seem to put 2 and 2 together and understand that the non Vista
compliant software that was installed is causing all kind of problems.

They are used to get a program that was running fine in 98, then XP and now
they expect the same to happen with Vista.

Not only that, I had a similar problem recently, the burner I have brough
nero 6.5, it was running fine in XP but is not compatible it seems with
Vista
My solution: I will have to buy the new version ( USD75) just to be able to
generate ISO in Vista

In reality Vista has been more problematic with backward compatibility than
XP was in relation to 98 or 2K.

IMO this is a price we have to pay to get rid of all the bad behaving apps .
Of course this has a more elevated cost to us as now we might have to
rewrite part of the apps.