I have a custom action to do a http post to send to google analytics for tracking installs. My custom action does other things and those are working. So I know my custom action is being called. I'm using HttpClient which requires a reference to System.Net.Http. I think the problem is with the reference. Is there something special i have to do in order to make sure the reference can be found?
I tested the code in a separate project to make sure the code works, and it does. When I try to run the msi it just fails to install. I put the whole http post inside a try statement to get by this, so at least the install doesn't fail.
Anyone got any ideas on what it could be or what to check?
UPDATED COMMENTS: In order to address the downvotes: accessing the Internet in your MSI setup is not advisable due to the overall nature of the MSI technology. It is an old technology not designed for the Internet age. It was designed to install Microsoft Office way back in the 90s (though there are rumors that the Windows Store might allow MSI files to be downloaded now in 2021).
Even accessing the local network from custom actions is difficult due to impersonation as SYSTEM when running in deferred mode (custom actions with admin access to system).
The normal situation is that
SYSTEMcontext can access the network via the machine account only. See mind map of this - the map is based on this SO answer.
Proxy servers,firewalls,security softwareandother mechanismscan interfere with non-system context custom actions trying to access the Internet. There could also beno user logged onwhen the package is deployed silently.Just write a flag to the registry and have the application report the fresh install or update on application launch instead?
Note on proxy servers: a proxy server for Internet access means the machine does not have direct Internet access, but must access the Internet via a machine dedicated as a "gateway". Back in the day I used to "discover" the proxy settings by reading IE settings, but overall: don't assume direct Internet access is available.
For reliability reasons setups should not do complicated things such as this. Can you do this from within your application instead? Then you will be in a more predictable impersonation context with full Internet access and with user interactivity - if needed. Much more reliable, easier to debug and you have interactivity with the user to sort out connection problems. And you can try again many times, if it fails at first. A setup is "one shot" in comparison - and much harder to debug.
Keep in mind that most corporate deployment is done in silent installation mode. When a setup runs in silent mode, you have to suppress all such fancy features that may require Internet access or interactivity of some sort. Accessing the Internet from a setup is an anti-pattern - at least for now - future online deployment techniques could change this truth. However, during a silent, corporate install your setup will likely run in system context with no Internet access at all (the SYSTEM account can not access the Internet - unless the network setup is crazy). You could also cause crashes trying to connect and triggering an exception, and you could trigger security software interference as well - it happens for "unusual setup behavior".
Even if a user runs your setup with a proper user context, there might be a proxy server that you have to access the web with - and then your connection will still fail unless you retrieve proxy settings from the system. I have never done that in a setup - again, since setups should not require Internet access in my opinion.
Keep in mind that the .NET framework is still not available in all "common versions" on all OS versions.
Hope that made sense to you. Please put this feature in your application. Tag the registry once the operation has run - if it should run only once. You can even write to HKLM if you open up some ACLs there to allow anyone to write the flag.
UPDATE: shortened summary. Doing this in your setup will fail if: