I have a .net dll
, it can be register by RegAsm
.net 3.5
and .net 4.5
I use this codes in my setup script:
[Run]
Filename: "{dotnet40}\RegAsm.exe"; Parameters: "my.dll"; WorkingDir: "{app}"; Flags: skipifdoesntexist; StatusMsg: "Registering Controls."
Filename: "{dotnet4064}\RegAsm.exe"; Parameters: "my.dll"; WorkingDir: "{app}"; Flags: skipifdoesntexist; StatusMsg: "Registering Controls."
Filename: "{dotnet20}\RegAsm.exe"; Parameters: "my.dll"; WorkingDir: "{app}"; Flags: skipifdoesntexist; StatusMsg: "Registering Controls."
Filename: "{dotnet2064}\RegAsm.exe"; Parameters: "my.dll"; WorkingDir: "{app}"; Flags: skipifdoesntexist; StatusMsg: "Registering Controls."
- It works well if .net 3.5 and .net 4.5 is installed on the target machine
- I have a function in my script to checking .net in
InitializeSetup
. so i know one of these versions are installed on the system: v3.5 v4 v4.5
But
we get error in some cases like this: if we have not .net 3.5 on the target machine
I guess the error reason is:
{dotnet20}
.NET Framework version 2.0 root directory. {dotnet20} is equivalent to {dotnet2032} unless the install is running in 64-bit mode, in which case it is equivalent to {dotnet2064}.
An exception will be raised if an attempt is made to expand this constant on a system with no .NET Framework version 2.0 present.
My question is how can i handle and ignore this exception and prevent setup rollback:
Internal error: .Net Framework version 2.0 not found.
If you want to stick to the
[Run]
section and do not write this in a scripting code, then I think you don't have many options to choose from. An exception is raised whenever a constant cannot be expanded, and that is just this case. The only option I can think of is adding aCheck
function that will attempt to expand the constant in a protectedtry..except
block and prevent the entry to be processed when an exception is raised. Something like follows (based on your code, shortened):Another, quite cleaner and a bit safer option would be doing your assembly registration purely from
[Code]
section in some of the postinstall events. Even though you'd still need to catch exceptions when using those constants, you would get more control over that tool (e.g. you could get the exit code to obtain an error reason if that tool uses it).