Hello All,

I have written a Visual Basic 2008 Application, developed using Visual Studio 2008 Professional. This Application is a Socket Server Application and interfaces with hardware and reads from and writes data a 2 different Access Database files.

In Debug Mode, it work perfectly and there are no error messages or warnings displayed in the output window.

If I Build the project and use that .exe file in the proejct directly to run the application, again it works perfectly.

However, if I copy that .exe file and associated files created to the Hardware Management Software installation directory, I find their isa problem. My Application can connect to the hardware and obtain the serial number from it and compare the serial number obtained to a list of registered serial numbers in one of the Access Database files. However, when it captures a data packet from the hardware and tries to write this data out to the second Access Database file, it fails.

I find I can publish the project but when it executes from the local/user directory it falls over becuase it does not copy the Access database files during the setup execution. However, if I shut down the application then and run it directly by clicking on the Project1.exe file in the local/user directory, after first manually copying the Access Database files to the local/user directory, it works perfectly.

However, if I again then copy the .exe file and assocaited files created to the Hardware Management Software installation directory and try to excute the Project1.exe file from there, the same problem as listed above occurs.

Also, if I Build the Application as a Setup Project, and install the Application directly into the Hardware Management Software installation directory and try to excute the Project1.exe file from there, again the same problem as listed above occurs.

I have set the Build Parameters to Build the Application in Release Mode. I am using Windows Vista Ultimate as my Operating System.

I wonder if anyone else has had similar problems as described above and manage to resolve them.

I would appreciate any guidance in this area.

Thanks in advance,

Nick

So I assume you are creating a setup & deployment project, and not using the Publish tab under your main project to deploy.

What other programs are installed in Vista that write data in the ProgramFiles? Not any commercial ones, I can guarantee you. Even Adobe (second in the software industry only to Microsoft) writes their cache and temp files and so on to an Adobe folder it creates under MyDocuments instead of in ProgramFiles like it used to.

You can disagree with my comments, but you will have problems with Vista. If the user has it turned on, Vista may allow data redirection (also known as data virtualization) that will basically put the files under the user's profile whether you like it or not. IF the user does not have that capability turned on, you will have problems. Also, Microsoft does not guarantee that functionality to be present in future versions of Windows.

Setting the application to Full Trust and running it as an Administrator basically goes against the guidelines of developing for Vista, which is to be able to run your application with the fewest permissions possible.

Here's some fun reading for you:

http://technet.microsoft.com/en-us/magazine/cc160980.aspx

Here's a highlight:

With so much emphasis on running as a standard user, there’s some concern about whether common LOB (line-of-business) applications will function correctly. To address this concern, the data redirection feature facilitates application compatibility. Data redirection, also known as data virtualization, provides a driver for the file system and registry that will redirect writes targeted at certain protected locations, such as HKEY_LOCAL_MACHINE\Software or %ProgramFiles%, to the user’s profile.

For example, if a member of the Users group is logged onto a machine and runs an application that writes a log file back to the Program Files directory, this write will fail. Why? Because the access control list (ACL) on the Program Files directory does not allow standard users to write to that location. When the data redirection file system driver receives the failed return code from this write, it redirects the write to a copy of the file made in the virtual store, a location in the user’s profile. An application that is marked with a run level in its manifest or that is a natively compiled 64-bit app is assumed to not require virtualization, so data redirection is disabled for that app. Windows binaries are marked with a run level, thereby disabling virtualization, and it is a requirement of the Windows Vista logo program that certified apps can run without data virtualization."

Here's Microsoft's info on UAC in Vista, the whys and wherefores:

http://msdn.microsoft.com/en-us/library/bb530410.aspx

There are guidelines regarding where to store the data files and such for Windows Vista available somewhere on Microsoft's site. I read them over a year ago when Vista first came out, and following them prepared me for deploying an application, completely with database, to thousands of users successfully. You might try searching for "vista" and "guidelines" and see if you can track them down, or maybe someone from MSFT will post the link.

Sometimes it's easier to swim with the current rather than try to either stay in the place you've been forever, or even swim upstream... But feel free to go your own way, and good luck with that.

RobinS.

GoldMail.com

It is unclear to me if you are using ClickOnce deployment (the Publish tab in your main project) or a Setup & Deployment package.

If you are using Vista, you probably can not write to a database installed under anywhere except the user's profile, like MyDocuments or Environment.LocalApplicationData, without takingsome serious steps (like turning off UAC). For Vista development, installing the data in ProgramFiles is basically a really bad idea.

So where exactly are you installing the application and the Access database?

RobinS.

GoldMail.com

Hello Robin,

As I wrote, I had tried using build alone, publish and build as a setup project.

The only method that worked correctly was build.

My Project directory is D:/Projects/Visual_Basic_2008/Client_Projects/Terminal_Managment_1.

By executing the Project1.exe file from that folder, the program ran correctly.

Using any other method, it failed.

I should be able to build a setup project and install the program anywhere, otherwsie their is a serious flaw with Visual Studio 2008 Professional.

Also, I set the Application Properties Security Setting to Full Trust and executed the different Project1.exe files as an Administrator on Vista.

How is it any other program installed in a folder under C:/Program Files has no trouble writing data to Access Database Files, while UAC is turned on?

I must disagree with your comments.

So I assume you are creating a setup & deployment project, and not using the Publish tab under your main project to deploy.

What other programs are installed in Vista that write data in the ProgramFiles? Not any commercial ones, I can guarantee you. Even Adobe (second in the software industry only to Microsoft) writes their cache and temp files and so on to an Adobe folder it creates under MyDocuments instead of in ProgramFiles like it used to.

You can disagree with my comments, but you will have problems with Vista. If the user has it turned on, Vista may allow data redirection (also known as data virtualization) that will basically put the files under the user's profile whether you like it or not. IF the user does not have that capability turned on, you will have problems. Also, Microsoft does not guarantee that functionality to be present in future versions of Windows.

Setting the application to Full Trust and running it as an Administrator basically goes against the guidelines of developing for Vista, which is to be able to run your application with the fewest permissions possible.

Here's some fun reading for you:

http://technet.microsoft.com/en-us/magazine/cc160980.aspx

Here's a highlight:

With so much emphasis on running as a standard user, there’s some concern about whether common LOB (line-of-business) applications will function correctly. To address this concern, the data redirection feature facilitates application compatibility. Data redirection, also known as data virtualization, provides a driver for the file system and registry that will redirect writes targeted at certain protected locations, such as HKEY_LOCAL_MACHINE\Software or %ProgramFiles%, to the user’s profile.

For example, if a member of the Users group is logged onto a machine and runs an application that writes a log file back to the Program Files directory, this write will fail. Why? Because the access control list (ACL) on the Program Files directory does not allow standard users to write to that location. When the data redirection file system driver receives the failed return code from this write, it redirects the write to a copy of the file made in the virtual store, a location in the user’s profile. An application that is marked with a run level in its manifest or that is a natively compiled 64-bit app is assumed to not require virtualization, so data redirection is disabled for that app. Windows binaries are marked with a run level, thereby disabling virtualization, and it is a requirement of the Windows Vista logo program that certified apps can run without data virtualization."

Here's Microsoft's info on UAC in Vista, the whys and wherefores:

http://msdn.microsoft.com/en-us/library/bb530410.aspx

There are guidelines regarding where to store the data files and such for Windows Vista available somewhere on Microsoft's site. I read them over a year ago when Vista first came out, and following them prepared me for deploying an application, completely with database, to thousands of users successfully. You might try searching for "vista" and "guidelines" and see if you can track them down, or maybe someone from MSFT will post the link.

Sometimes it's easier to swim with the current rather than try to either stay in the place you've been forever, or even swim upstream... But feel free to go your own way, and good luck with that.

RobinS.

GoldMail.com