Deployment Project/MSI/installer problems

  • Thread starter Thread starter Arun Bhalla
  • Start date Start date
A

Arun Bhalla

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
Support.) I have a few issues and questions regarding the MSI and its
properties.

* This may be my biggest annoyance at the moment. When the installer creates
the target directory, it's setting them as read-only. When the application
is uninstalled, the target directory is not deleted, although it's empty. I
presume this is because the target directory is read-only and the installer
doesn't try to force the removal, but I'm not positive. Why is this
happening, anyway, and how can I correct it. I'm not certain if this has
always been a problem for me with this project, but it's also not a recently
new problem.

* When the user opts to install for "Everyone," I need to modify the
registry for all users. I'm not sure there's a reasonable way to do this
within VS.NET's IDE (or otherwise?). The User/Machine Hive is an alias for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
useful (ever) for setting within the .DEFAULT tree, but that doesn't handle
current users. I've seen a reference to HKEY_PER_USER, which seems like what
I'd want, but I don't know how to access it, and there's almost zero
documentation online, so maybe it's vaporware. I suppose I could handle this
programmatically, in a custom action, but it seems like a common enough
need, and I'd rather have the installer handle as much as possible, anyhow!
Plus, how can the custom action know that it's supposed to set keys for all
users? Can the custom actions access the MSI's runtime properties?

* For that matter, I'm not sure there's a good way for users' configurations
to be retained during an upgrade, and possibly my real problem here is that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the installer is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?

* There doesn't seem to be a good way for defining deployment projects in
terms of solution configurations. For instance, I can configure the project
within a certain solution configuration (e.g. Debug) to add some conditional
compilation constants (e.g. TRACE, DEBUG), and I can use those constants in
my code within #if blocks. How can I do something similar within a
deployment project? One solution I've heard is to create a different
deployment project for each solution configuration that has its own needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun
 
Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else
going on there. Normally they do really get removed on an uninstall unless
there are files created by programs still in there.

The usual way to do registry entries for all users is to put them in HKEY
users (you might need to put them in HKCU too). I don't know if Visual
Studio has support for this general scheme, but once you do that, when a new
user logs on and attempts to access those registry entries they are missing
for the new user, and the repair mechanism kicks in and installs them.
That's the general way that user-specific data is installed for each new
user.

Preserving user configurations is partly a design issue, and partly a
maintenance issue. Again, some of this is related to the the way Visual
Studio encourages updates (RemovePreviousVersions), but other tools make it
easier to build patches (msp files) or do minor upgrades (reinstalling the
same MSI file with updated files). If you use the exact same setup (to
preserve ProductCode and internal installer Guids in the MSI file) and just
replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, a
concrete example might be useful.

It looks like you're stretching the capabilities of Visual Studio setup
projects, and there's a reason why all these other tools exist - many have
more capabilties that you might be able to use.
http://installsite.org/pages/en/msi/authoring.htm
 
Hi Phil,

Thanks for your comments.

It seems like there's something going on blocking the removal of TARGETDIR,
but I can't figure it out. When I log everything (*v) with MsiExec, I don't
see any errors. It says that installation/removal occurred successfully
with no errors. There are no files, hidden or not, in TARGETDIR. One
possibly telling thing is that I don't see any indication that MsiExec tries
to remove TARGETDIR, but I can't explain why that would happen.

I don't understand how the repair mechanism you describe is supposed to
work. If you are implying that if I add a key to HKEY_USERS\.DEFAULT\....,
and when a user logs on and some software (e.g. IE) detects that a new key
in .DEFAULT isn't in HKCU but should be and then installs the key there,
that doesn't seem to be the case. Unless someone says otherwise, it seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

Phil Wilson said:
Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else
going on there. Normally they do really get removed on an uninstall unless
there are files created by programs still in there.

The usual way to do registry entries for all users is to put them in HKEY
users (you might need to put them in HKCU too). I don't know if Visual
Studio has support for this general scheme, but once you do that, when a new
user logs on and attempts to access those registry entries they are missing
for the new user, and the repair mechanism kicks in and installs them.
That's the general way that user-specific data is installed for each new
user.

Preserving user configurations is partly a design issue, and partly a
maintenance issue. Again, some of this is related to the the way Visual
Studio encourages updates (RemovePreviousVersions), but other tools make it
easier to build patches (msp files) or do minor upgrades (reinstalling the
same MSI file with updated files). If you use the exact same setup (to
preserve ProductCode and internal installer Guids in the MSI file) and just
replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, a
concrete example might be useful.

It looks like you're stretching the capabilities of Visual Studio setup
projects, and there's a reason why all these other tools exist - many have
more capabilties that you might be able to use.
http://installsite.org/pages/en/msi/authoring.htm

--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Arun Bhalla said:
I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
Support.) I have a few issues and questions regarding the MSI and its
properties.

* This may be my biggest annoyance at the moment. When the installer
creates
the target directory, it's setting them as read-only. When the application
is uninstalled, the target directory is not deleted, although it's empty.
I
presume this is because the target directory is read-only and the
installer
doesn't try to force the removal, but I'm not positive. Why is this
happening, anyway, and how can I correct it. I'm not certain if this has
always been a problem for me with this project, but it's also not a
recently
new problem.

* When the user opts to install for "Everyone," I need to modify the
registry for all users. I'm not sure there's a reasonable way to do this
within VS.NET's IDE (or otherwise?). The User/Machine Hive is an alias for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
useful (ever) for setting within the .DEFAULT tree, but that doesn't
handle
current users. I've seen a reference to HKEY_PER_USER, which seems like
what
I'd want, but I don't know how to access it, and there's almost zero
documentation online, so maybe it's vaporware. I suppose I could handle
this
programmatically, in a custom action, but it seems like a common enough
need, and I'd rather have the installer handle as much as possible,
anyhow!
Plus, how can the custom action know that it's supposed to set keys for
all
users? Can the custom actions access the MSI's runtime properties?

* For that matter, I'm not sure there's a good way for users'
configurations
to be retained during an upgrade, and possibly my real problem here is
that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the installer is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?

* There doesn't seem to be a good way for defining deployment projects in
terms of solution configurations. For instance, I can configure the
project
within a certain solution configuration (e.g. Debug) to add some
conditional
compilation constants (e.g. TRACE, DEBUG), and I can use those constants
in
my code within #if blocks. How can I do something similar within a
deployment project? One solution I've heard is to create a different
deployment project for each solution configuration that has its own needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun
Click to expand...
Click to expand...
 
Well, I'd add registry entries using a custom action if I could somehow
detect deployment properties such as ALLUSERS within my installer custom
action (of type System.Configuration.Install.Installer).

Arun

Arun Bhalla said:
I don't understand how the repair mechanism you describe is supposed to
work. If you are implying that if I add a key to HKEY_USERS\.DEFAULT\....,
and when a user logs on and some software (e.g. IE) detects that a new key
in .DEFAULT isn't in HKCU but should be and then installs the key there,
that doesn't seem to be the case. Unless someone says otherwise, it seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

Phil Wilson said:
Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else
going on there. Normally they do really get removed on an uninstall unless
there are files created by programs still in there.

The usual way to do registry entries for all users is to put them in HKEY
users (you might need to put them in HKCU too). I don't know if Visual
Studio has support for this general scheme, but once you do that, when a new
user logs on and attempts to access those registry entries they are missing
for the new user, and the repair mechanism kicks in and installs them.
That's the general way that user-specific data is installed for each new
user.

Preserving user configurations is partly a design issue, and partly a
maintenance issue. Again, some of this is related to the the way Visual
Studio encourages updates (RemovePreviousVersions), but other tools make it
easier to build patches (msp files) or do minor upgrades (reinstalling the
same MSI file with updated files). If you use the exact same setup (to
preserve ProductCode and internal installer Guids in the MSI file) and just
replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there, a
concrete example might be useful.

It looks like you're stretching the capabilities of Visual Studio setup
projects, and there's a reason why all these other tools exist - many have
more capabilties that you might be able to use.
http://installsite.org/pages/en/msi/authoring.htm

--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Arun Bhalla said:
I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
Support.) I have a few issues and questions regarding the MSI and its
properties.

* This may be my biggest annoyance at the moment. When the installer
creates
the target directory, it's setting them as read-only. When the application
is uninstalled, the target directory is not deleted, although it's empty.
I
presume this is because the target directory is read-only and the
installer
doesn't try to force the removal, but I'm not positive. Why is this
happening, anyway, and how can I correct it. I'm not certain if this has
always been a problem for me with this project, but it's also not a
recently
new problem.

* When the user opts to install for "Everyone," I need to modify the
registry for all users. I'm not sure there's a reasonable way to do this
within VS.NET's IDE (or otherwise?). The User/Machine Hive is an alias for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
useful (ever) for setting within the .DEFAULT tree, but that doesn't
handle
current users. I've seen a reference to HKEY_PER_USER, which seems like
what
I'd want, but I don't know how to access it, and there's almost zero
documentation online, so maybe it's vaporware. I suppose I could handle
this
programmatically, in a custom action, but it seems like a common enough
need, and I'd rather have the installer handle as much as possible,
anyhow!
Plus, how can the custom action know that it's supposed to set keys for
all
users? Can the custom actions access the MSI's runtime properties?

* For that matter, I'm not sure there's a good way for users'
configurations
to be retained during an upgrade, and possibly my real problem here is
that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the installer is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate forward?

* There doesn't seem to be a good way for defining deployment projects in
terms of solution configurations. For instance, I can configure the
project
within a certain solution configuration (e.g. Debug) to add some
conditional
compilation constants (e.g. TRACE, DEBUG), and I can use those constants
in
my code within #if blocks. How can I do something similar within a
deployment project? One solution I've heard is to create a different
deployment project for each solution configuration that has its own needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun
Click to expand...
Click to expand...
Click to expand...
 
I didn't describe it accurately - it's actually HKCU where you install the
registry entries, even for a per-machine install. When a different user (the
non-installing user) logs on, an entry point (typically a shortcut) causes a
check that those entries are present, and of course they will not be there
for that user. The repair then installs those entries - you'd see a brief
Windows Installer dialog box with a progress bar. The scheme requires
ensuring that the registry entries are a keypath of the component, and
Visual Studio doesn't have a lot of control in that area. This article is a
general one that refers to repair in Office, and mentions keypaths and
repairs, the idea being that missing files or registry entries get repaired,
and therefore is often used to install registry entries for new users.
http://support.microsoft.com/default.aspx?scid=kb;en-us;290526

It's very difficult to install registry keys for all users because of the
requirement to enumerate all the users in the registry, and that design also
fails to take account of new users who log on after you install the product.
I suggest you do a test - it wouldn't take long to build an MSI with some
registry entries in HKCU, install it per-machine, log in as another user and
see if the entries get installed as I described.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Arun Bhalla said:
Hi Phil,

Thanks for your comments.

It seems like there's something going on blocking the removal of
TARGETDIR,
but I can't figure it out. When I log everything (*v) with MsiExec, I
don't
see any errors. It says that installation/removal occurred successfully
with no errors. There are no files, hidden or not, in TARGETDIR. One
possibly telling thing is that I don't see any indication that MsiExec
tries
to remove TARGETDIR, but I can't explain why that would happen.

I don't understand how the repair mechanism you describe is supposed to
work. If you are implying that if I add a key to
HKEY_USERS\.DEFAULT\....,
and when a user logs on and some software (e.g. IE) detects that a new key
in .DEFAULT isn't in HKCU but should be and then installs the key there,
that doesn't seem to be the case. Unless someone says otherwise, it seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

Phil Wilson said:
Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else
going on there. Normally they do really get removed on an uninstall
unless
there are files created by programs still in there.

The usual way to do registry entries for all users is to put them in HKEY
users (you might need to put them in HKCU too). I don't know if Visual
Studio has support for this general scheme, but once you do that, when a new
user logs on and attempts to access those registry entries they are missing
for the new user, and the repair mechanism kicks in and installs them.
That's the general way that user-specific data is installed for each new
user.

Preserving user configurations is partly a design issue, and partly a
maintenance issue. Again, some of this is related to the the way Visual
Studio encourages updates (RemovePreviousVersions), but other tools make it
easier to build patches (msp files) or do minor upgrades (reinstalling
the
same MSI file with updated files). If you use the exact same setup (to
preserve ProductCode and internal installer Guids in the MSI file) and just
replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there,
a
concrete example might be useful.

It looks like you're stretching the capabilities of Visual Studio setup
projects, and there's a reason why all these other tools exist - many
have
more capabilties that you might be able to use.
http://installsite.org/pages/en/msi/authoring.htm

--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Arun Bhalla said:
I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP SP1. My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
Support.) I have a few issues and questions regarding the MSI and its
properties.

* This may be my biggest annoyance at the moment. When the installer
creates
the target directory, it's setting them as read-only. When the application
is uninstalled, the target directory is not deleted, although it's empty.
I
presume this is because the target directory is read-only and the
installer
doesn't try to force the removal, but I'm not positive. Why is this
happening, anyway, and how can I correct it. I'm not certain if this
has
always been a problem for me with this project, but it's also not a
recently
new problem.

* When the user opts to install for "Everyone," I need to modify the
registry for all users. I'm not sure there's a reasonable way to do
this
within VS.NET's IDE (or otherwise?). The User/Machine Hive is an alias for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
useful (ever) for setting within the .DEFAULT tree, but that doesn't
handle
current users. I've seen a reference to HKEY_PER_USER, which seems like
what
I'd want, but I don't know how to access it, and there's almost zero
documentation online, so maybe it's vaporware. I suppose I could handle
this
programmatically, in a custom action, but it seems like a common enough
need, and I'd rather have the installer handle as much as possible,
anyhow!
Plus, how can the custom action know that it's supposed to set keys for
all
users? Can the custom actions access the MSI's runtime properties?

* For that matter, I'm not sure there's a good way for users'
configurations
to be retained during an upgrade, and possibly my real problem here is
that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the installer is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate
forward?

* There doesn't seem to be a good way for defining deployment projects in
terms of solution configurations. For instance, I can configure the
project
within a certain solution configuration (e.g. Debug) to add some
conditional
compilation constants (e.g. TRACE, DEBUG), and I can use those
constants
in
my code within #if blocks. How can I do something similar within a
deployment project? One solution I've heard is to create a different
deployment project for each solution configuration that has its own needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun
Click to expand...
Click to expand...
Click to expand...
 
Hmm, I just built an installer and ran it per-machine ("Everyone") with it
installing entries in HKCU. It didn't carry over to the test user account I
had created earlier this week.

I assume that new users' registry hives are initalized with
HKEY_USERS\.DEFAULT, but that might be a bad assumption -- it makes too much
sense!

Thanks,
Arun


Phil Wilson said:
I didn't describe it accurately - it's actually HKCU where you install the
registry entries, even for a per-machine install. When a different user (the
non-installing user) logs on, an entry point (typically a shortcut) causes a
check that those entries are present, and of course they will not be there
for that user. The repair then installs those entries - you'd see a brief
Windows Installer dialog box with a progress bar. The scheme requires
ensuring that the registry entries are a keypath of the component, and
Visual Studio doesn't have a lot of control in that area. This article is a
general one that refers to repair in Office, and mentions keypaths and
repairs, the idea being that missing files or registry entries get repaired,
and therefore is often used to install registry entries for new users.
http://support.microsoft.com/default.aspx?scid=kb;en-us;290526

It's very difficult to install registry keys for all users because of the
requirement to enumerate all the users in the registry, and that design also
fails to take account of new users who log on after you install the product.
I suggest you do a test - it wouldn't take long to build an MSI with some
registry entries in HKCU, install it per-machine, log in as another user and
see if the entries get installed as I described.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Arun Bhalla said:
Hi Phil,

Thanks for your comments.

It seems like there's something going on blocking the removal of
TARGETDIR,
but I can't figure it out. When I log everything (*v) with MsiExec, I
don't
see any errors. It says that installation/removal occurred successfully
with no errors. There are no files, hidden or not, in TARGETDIR. One
possibly telling thing is that I don't see any indication that MsiExec
tries
to remove TARGETDIR, but I can't explain why that would happen.

I don't understand how the repair mechanism you describe is supposed to
work. If you are implying that if I add a key to
HKEY_USERS\.DEFAULT\....,
and when a user logs on and some software (e.g. IE) detects that a new key
in .DEFAULT isn't in HKCU but should be and then installs the key there,
that doesn't seem to be the case. Unless someone says otherwise, it seems
that VS.NET 2003 doesn't have the capability to install keys for all users
without using a custom action.

Thanks,
Arun

Phil Wilson said:
Some general comments:

It's not unusual for those folders to be marked read-only, but that's not
the reason your folders are not being removed - there must be something else
going on there. Normally they do really get removed on an uninstall
unless
there are files created by programs still in there.

The usual way to do registry entries for all users is to put them in HKEY
users (you might need to put them in HKCU too). I don't know if Visual
Studio has support for this general scheme, but once you do that, when
Click to expand...
a
new
user logs on and attempts to access those registry entries they are missing
for the new user, and the repair mechanism kicks in and installs them.
That's the general way that user-specific data is installed for each new
user.

Preserving user configurations is partly a design issue, and partly a
maintenance issue. Again, some of this is related to the the way Visual
Studio encourages updates (RemovePreviousVersions), but other tools
Click to expand...
make
it
easier to build patches (msp files) or do minor upgrades (reinstalling
the
same MSI file with updated files). If you use the exact same setup (to
preserve ProductCode and internal installer Guids in the MSI file) and just
replace existing files with higher versioned ones, msiexec /i <your msi>
REINSTALL=ALL REINSTALLMODE=vomus should update the files.

That final point, I don't get a good feel for what you want to do there,
a
concrete example might be useful.

It looks like you're stretching the capabilities of Visual Studio setup
projects, and there's a reason why all these other tools exist - many
have
more capabilties that you might be able to use.
http://installsite.org/pages/en/msi/authoring.htm

--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

I'm working with VS.NET 2003 and .NET 1.1 (not SP1) on Windows XP
Click to expand...
SP1.
My
application is using the Windows Installer Bootstrap. (I may have also
installed a module which detects requirements (.NET 1.1 -> MsiNetAssembly
Support.) I have a few issues and questions regarding the MSI and its
properties.

* This may be my biggest annoyance at the moment. When the installer
creates
the target directory, it's setting them as read-only. When the application
is uninstalled, the target directory is not deleted, although it's empty.
I
presume this is because the target directory is read-only and the
installer
doesn't try to force the removal, but I'm not positive. Why is this
happening, anyway, and how can I correct it. I'm not certain if this
has
always been a problem for me with this project, but it's also not a
recently
new problem.

* When the user opts to install for "Everyone," I need to modify the
registry for all users. I'm not sure there's a reasonable way to do
this
within VS.NET's IDE (or otherwise?). The User/Machine Hive is an
Click to expand...
alias
for
HKLM when "Everyone" is selected, so that's no help. HKEY_USERS only seems
useful (ever) for setting within the .DEFAULT tree, but that doesn't
handle
current users. I've seen a reference to HKEY_PER_USER, which seems like
what
I'd want, but I don't know how to access it, and there's almost zero
documentation online, so maybe it's vaporware. I suppose I could handle
this
programmatically, in a custom action, but it seems like a common enough
need, and I'd rather have the installer handle as much as possible,
anyhow!
Plus, how can the custom action know that it's supposed to set keys for
all
users? Can the custom actions access the MSI's runtime properties?

* For that matter, I'm not sure there's a good way for users'
configurations
to be retained during an upgrade, and possibly my real problem here is
that
I have RemovePreviousVersions set to True. But if an installer is supposed
to remove its files and registry keys it created, and if the
Click to expand...
installer
is
supposed to first uninstall previous versions (which makes sense in my
case), then how are previous configurations supposed to migrate
forward?

* There doesn't seem to be a good way for defining deployment
Click to expand...
projects
in
terms of solution configurations. For instance, I can configure the
project
within a certain solution configuration (e.g. Debug) to add some
conditional
compilation constants (e.g. TRACE, DEBUG), and I can use those
constants
in
my code within #if blocks. How can I do something similar within a
deployment project? One solution I've heard is to create a different
deployment project for each solution configuration that has its own needs.
That seems like a management nightmare beyond the simple case!

Thanks for any comments or answers you might provide.

Arun
Click to expand...
Click to expand...
Click to expand...
 
Back
Top