Strange Behavior in Win 7 64

[crmfghtr]

Hello,
I created a setup using sb7 developer. The issue is this on my test computer which is win 7 home premium 64 My software installs all the files as required. When i try to launch the software on the test machine, the program does not open, I get no error messages, and Nothing happens. I tried opening the task manager to see if the software is actually loaded, and there is nothing listed, however i see the memory usage is at about 33%. Any ideas what might be happening here. I can't duplicate the problem on the developement system because I get no errors and everything uploads / downloads just fine.
Any help ?

[linder]

Hello,

This is not related to SetupBuilder. You have to find out why your program does not work. For example, is your application UAC-aware, is your installation strategy UAC-aware, is your application Windows 7 and x64 compatible, etc. If your application depends on a specific runtime (e.g. Visual C++ runtime), make sure that the correct version is available.

I would suggest to add some debug messages to your program to find out where it "hangs". This can help to fix the bug.

Does this help?

Friedrich

[crmfghtr]

The program was created in VS2010 Pro (VB.NET) against the .NET Framework 4.0 Client. As I mentioned earlier, all the files are installed corectly, I have 2 test machines, 1-XP, 1-Win-7 Home Premium. I suspect it is a UAC issue. I have re-set the installation path to the %CLID_COMMON_DOCUMENTS% and lowered the permissions to As Invoker to see if this is causing the issue. Before, the program would install into the Program Files Directory. On the XP machine, The program works in the Program Files Folder. I will let you know what happens.
Thanks,
Robert

[linder]

Hi Robert,

According to the Windows Development Guidelines, you should not install any program to CSIDL_COMMON_DOCUMENTS. Never! This folder should only contain document files that are common to all users. And if you set the "UAC Execution Level" to asInvoker then your install has no access to protected Windows resources on UAC-aware operating systems. So if you try to register OCX files or register .NET assemblies, then this will fail bceucause you need administrator execution level privileges to handle this.

BTW, try to execute your application on your XP machine in a locked down environment (login to a "Limited User" account and then try to start it). If your application is not UAC-compatible then it will also fail on your XP machine when running from the Limited User account.

Hope this helps.

Friedrich

[crmfghtr]

Hello,
I think maybe the issue here is the .NET 4.0 redistributive included with SB7. My app references the .NET 4.0 Client framework. The redist version included with SB7 runtimes is the .NET 4.0 FULL version. My test computers had the full.net 4.0 framework installed. I uninstalled the full version and installed the .NEt 4.0 Client version and now the programs open as required. I don't know why, maybe because the .NET 4.0 client is optimized for VB.NET.Are there plans to offer a .NET 4.0 Client runtime version script to include with my app. Or could you offer some example on how to determine if the .NET 4.0 client is installed and install it as necessary.

Thanks,

[linder]

Hello,

Here are some interesting information:

The Microsoft .NET Framework 4 Client Profile provides a subset of features from the .NET Framework 4. The Client Profile is designed to run client applications and to enable the fastest possible deployment for Windows Presentation Foundation (WPF) and Windows Forms technology. Application developers who require features that are not included in the Client Profile should target the full .NET Framework 4 instead of the Client Profile."

If you are targeting the .NET Framework 4 Client Profile, you cannot reference an assembly that is not in the .NET Framework 4 Client Profile. Instead you must target the .NET Framework 4.

If your application targets the .NET Framework 4 Client Profile, you can add a reference to a class library that targets the .NET Framework 4 as long as that library does not reference any assemblies not included in the .NET Framework 4 Client Profile. If the library does include references to assemblies not in the .NET Framework 4 Client Profile, then Visual Studio will display an error message.

When you deploy an application that targets the .NET Framework 4 Client Profile, you only need to deploy the .NET Framework 4 Client Profile. If you are deploying using ClickOnce, you can select the .NET Framework 4 Client Profile as the .NET Framework Launch Condition.

If you deploy the .NET Framework 4 Client Profile and your application targets the .NET Framework 4, the user will be prompted to install the .NET Framework 4 when he or she tries to run your application.

When you deploy an application that targets the .NET Framework 4 Client Profile, you only need to deploy the .NET Framework 4 Client Profile (
dotNetFx40_Client_x86_x64.exe). You can use the .NET4 include script as an example on how to build your own redistributable.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24872

Hope this helps.

Friedrich

[crmfghtr]

Hi,
I built the application to run on the .NET 4.0 Client. If I reference the SB7 script for .NET for won't this detect only the Full version? I'm frankly at a loss on how to do this. My script writing knowledge is limited. How do you retrieve the .NET 4.0 Client(86x64).exe before the app is actually installed? Should I include the .NET 4.0 client setup with my installation or upload it to a folder on my ISP host and download it from the script if it is needed ? Any help would be appreciated.

Should I check the registry for client like this ?


Set Variable %SYSDIR% to FUNCTION:Get System Info(WOW64 Status)
! Check for 64 Bit or 32 Bit operating system
If %SYSDIR% Equals "1" Then
! Check if the .NET 4.0 Client is Installed on a 64 Bit System
Set Variable %DOTNET4% to FUNCTION:Get Registry Key Value("Install") from "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432node\Microsoft\ NET Framework Setup\NDP\v4\Client"
Else
! This is a 32 Bit System, Check if the .NET 4.0 Client is installed
Set Variable %DOTNET4% to FUNCTION:Get Registry Key Value("Install") from "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client"
End
End

Thanks,

[linder]

Hello,

First of all, never specify the "Wow6432node" registry item in Windows!

See: http://www.lindersoft.com/forums/showthread.php?p=55605#post55605

You have to enable/disable 64-bit processing in your install (see "Set x64 Mode..." script function) to get access to the native 32-bit and native 64-bit registry branch.

Then you have in your code snippet:

Set Variable %SYSDIR% to FUNCTION:Get System Info(WOW64 Status)

Don't do this. You overwrite the %SYSDIR% value here. Define your own variable, e.g. %IS_64BIT%

You have several completely different options to handle the NET 4.0 Client install. For example, you can "host" the original Microsoft redistributable on your own web site and download (see "Download File (HTTP)..." script function) and install it from your setup.exe if required (advantage: smaller setup.exe size). Or you can package the redistributable directly into your setup.exe (advantage: no active Internet connection is required).

Does this help?

Friedrich