1

The extension Visual Studio Installer Projects was dropped at some point - about 10 years ago. Protests from many developers caused Microsoft to change its mind and the extension was reintroduced and then left unchanged as far as I know. I have worked with it for a long time - actually to package applications built outside Visual Studio (i.e. Delphi and Java stuff). This worked well until recently. Now a dependency is somehow detected for .NET Framework 4.7.2, but my colleagues assured me that it is not needed. I cannot remove this dependency. And I could not remove the associated launch condition either. I even tried to hack the *.vdproj file by removing some JSON from it that referred to the .NET framework, but to no avail. When I added a second project to the solution, I was able to at least remove the launch condition that would prompt the user to install the framework. I was able to save the solution like that. However: when I clicked to start the build process, the launch condition was added again before the actual process started. Does anybody know any other trick which I could use?enter image description here

Dobedani
  • 508
  • 5
  • 20
  • I skimmed this quickly, and write in a rush, but if I understand correctly, you could just use Orca to remove the LaunchConditions from the MSI after build? [Have a look here please](https://stackoverflow.com/a/58934153/129130) - [odd one here](https://stackoverflow.com/q/56348231/129130). Also, there are too many problems with these VS installer projects. [Summary here](https://stackoverflow.com/a/47944893/129130). You probably don't want to hear it, but [please evaluate another deployment tool](https://stackoverflow.com/a/50229840/129130)? Any screenshots of your project settings? – Stein Åsmul Dec 10 '20 at 13:25
  • Just for the record: you can use Orca to delete the launch conditions in the LaunchCondition table. Generally not proper practice, but it will work. Do not do this with MSI files that are signed - this will break the digital signature. – Stein Åsmul Dec 10 '20 at 13:34
  • Okay, I tried Orca. The table LaunchCondition of my MSI file appears to be empty - unfortunately - so nothing to remove. I searched for ".NET Framework" and found e.g. VSDFrameworkVersion under Property with value .NET Framework 4.7.2". I have no clue though whether tampering with this property would have any effect. BTW, I have added a screenshot of my VS solution in Visual Studio above. – Dobedani Dec 10 '20 at 15:12
  • Check the attempted answer below. I tried with VS2019. I never use this VS Installer Project type, but I think the approach below should work. Keep in mind that you should do a bit of testing to verify. What .NET version do you need anyway? Nothing that isn't built-in? Some later discoveries added to top of answer. – Stein Åsmul Dec 10 '20 at 23:18
  • In the meantime, I found a VS extension called "Visual & Installer", see: https://www.visual-installer.com/. I installed it into VS2019. Well, I was unable to get it working, but I found the added programme SetupProjectsConverter.exe: it helped me to convert my VDPROJ file into an ISS file. Yes, I decided already last year to gain experience also with another MSI tool, i.e. InnoSetup. The produced ISS file was okay: InnoSetup produced an MSI file which does not cause disturbance for the users. Problem solved! – Dobedani Dec 11 '20 at 11:20
  • I was not aware that InnoSetup could produce MSI files? [Are you sure?](https://jrsoftware.org/isfaq.php#msi) Maybe it is a different tool and not InnoSetup? Or some brand new feature? – Stein Åsmul Dec 11 '20 at 12:54
  • You're right. It's an EXE file that installs the application. Sorry! – Dobedani Dec 11 '20 at 23:39
  • As long as it works to your satisfaction that would do the job. However, there are [some important benefits to MSI files](https://stackoverflow.com/a/49632260/129130). – Stein Åsmul Dec 12 '20 at 00:28

1 Answers1

1

Disclaimer: Added after the below answer. Please skim. Strongly recommend you consider a more capable and transparent MSI tool (no surprises like these) if you plan to keep delivering your software. Just for the record: 1) Problem list VS Installer projects. 2) Even longer list.

  1. I am not sure what the custom action CheckFX does. You might need to disable this custom action too. Update: After more testing I think you should leave this action in.

  2. There are also two interesting properties in the Property table:

    • VSDFrameworkVersion = v4.6.1
    • VSDAllowLaterFrameworkVersions = False

These properties might be possible to manipulate to change the behavior of the custom actions mentioned below. Particularly the VSDAllowLaterFrameworkVersions looks interesting. Try setting it to "True" and test on your target platforms? My quick test seemed ineffective.

Overall Recommendation: The summary of it all is that 1) I suggest you use a better tool if you need this to work properly in the future without "black box surprises" (you don't know how things really work). 2) The "solution" to disable the VSDCA_VsdLaunchConditions custom action as described below should work though. 3) Please test thoroughly on all target OS versions. Remember upgrade scenarios and uninstall. 4) You could try those properties in the property table (VSDFrameworkVersion, VSDAllowLaterFrameworkVersions). Various settings. I didn't discover anything in particular after a smoke test.

Prerequisites: The first proposed solution I added (at the bottom of this answer now) will remove the dependency on the .NET framework to look at, but it seems there is a custom action in the MSI which will check for the baseline .NET version anyway. It is called: VSDCA_VsdLaunchConditions.

Hack MSI: To prevent any checks for the .NET framework you can hack the MSI as follows:

  1. Open your MSI with Orca.
  2. In the InstallExecuteSequence table locate VSDCA_VsdLaunchConditions and change its condition by adding: "AND 0" to what is there already. This will prevent the custom action from running at all.
  3. Continue in the InstallUISequence table. Locate VSDCA_VsdLaunchConditions and change its condition by adding: "AND 0" to what is there already.
  4. Save the MSI and do a test install on a box without recent versions of the .NET framework (some are built-in on most OS versions now).

Always False Condition: AND 0 makes the condition for the sequence custom action always false - which means it never runs. You can also delete the custom action itself, but that would generate some dangling foreign keys - this approach should not do so.

MSI Tables: The InstallExecuteSequence table runs the installation. The InstallExecuteSequence table runs the setup GUI - both locations must be modified to prevent any .NET checks.

Consequences: Side-effects of this approach should be minimal (unless your application really does require a specific, higher version of the .NET framework), but I don't know what else goes on in that custom action.

Custom Action DLL: The actual custom action binary inside the VS Installer Project seems to be capable of a lot of things, but this functionality should inject other custom actions than the above dependency custom action. Looking at the exported functions of the dll it seems most calls relate to IIS functionality:

Dependency Walker

Below is the original answer. It seems to prevent the bundling of .NET frameworks with your MSI, but it seems there is a "baseline check" anyway for a "lowest possible" version of the .NET framework. For Visual Studio 2019 this seems to be .NET 4.6.

When you right click the main project and go properties do you see the "Prerequisites" dialog as shown here? Here you can change what prerequisites your setup bundles:

  1. In the top left corner, select your "Release" configuration.

    Release configuration

  2. Now press the "Prerequisites" button to get this dialog:

    Prerequisites

  3. Adjust the required version of the .NET framework - or remove the dependency.

Note that this is done by the setup.exe launcher and not the MSI it seems. You should be able to run the MSI itself or the setup.exe launcher. The latter will install the .NET framework specified (if missing), and the MSI installed on its own should not.

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164