We Keep Coding

Bypass restrictions of enabled Folder Access Control of Windows Defender

I've got an application written with C# which is installed via InnoSetup.
With enabled Controlled Folder Access of Windows 10's Defender, the setup fails to create a desktop icon (showing the message PersistFile::Save failed, code 0x80070002) -- despite running with administrative privileges.
Furthermore the installed application (which is NOT run with administrative privileges) fails to write to folders of the user, e.g. Documents.
This happens even for new files or folders, which do not overwrite anything existing. For ransomware protection I'd expect that only modifying existing files is considered dangerous.
The first question that comes to my mind is: Why is my application considered to be harmful and is thus being blocked?
I've done extensive research to get an answer, but could not find anything that helps:
Web resources from Mircosoft describing which applications are considered harmful and why cannot be found -- only guesswork there.
Signing my application with an Extended Validation Certificate (which helps suppressing SmartScreen warnings) does not change Windows Defender's behavior.
I let the Windows App Certification Kit analyze the installer -- which reported several warnings and one critical error. I fixed all issues the Kit complained about (except the warning regarding /SAFESEH which is not possible with InnoSetup), but this did not change Windows Defender's behavior regarding access blocking.
So, my refined question is: How can I bypass the access blocking of Windows Defender for my setup and my application in a valid way?
To give insights to the problem and to provide a basis for experiments I've set up a small sample application in C# which
creates new (and afterwards removes) directories in the public desktop path, user's desktop path, pulic documents path and user's documents path
is bundled by an InnoSetup script to a signed installer
Using Visual Studio to build the solution and InnoSetup to package the build, it should be easy to reproduce the behavior with enabled Controlled Folder Access. (Make sure to have a look at README.md for a description of the build steps!)
Please check out the sample project.

Issue faced during uninstall MSI using its Product Code in c#(DTF)

I am creating a CustomBA which will replace the existing install shield Bootstrapper( I don't really know what it's called).
We are installing the same number of MSI as the install shield use to do, so no problem in that.
All the MSI entries in the ARP are removed, as we are making MSI's Visible="no".
Only the Custom BA entry is available in the ARP along with the Install shield Bootstrapper entry, both having the same name.
So after some research I got to know that Windows Installer XML (WiX) ships the Microsoft.Deployment.WindowsInstaller interop library as part of Deployment Tools Foundation (DTF), which can be used to uninstall the MSI.
I am using the below code to uninstall the MSI.
Microsoft.Deployment.WindowsInstaller.Installer.SetInternalUI(InstallUIOptions.Silent);
Microsoft.Deployment.WindowsInstaller.Installer.EnableLog(InstallLogModes.Info, #"C:\Uninstall.log");
Microsoft.Deployment.WindowsInstaller.Installer.ConfigureProduct(productCode, 0, InstallState.Absent, "");
Issue that I am facing are as mentioned below
Firstly I have to run the CustomBA as Administrator to uninstall the existing MSI else it throw as error "Error 1730.You must be an Administrator to remove this application.". Is there a way to run the CustomBA without Administrator and uninstall the MSI.
While uninstall( when I run the customBA as admin), the above mentioned code also remove's the chain packages with it, which I don't want it to do.
After the uninstallation code has been run it does not remove the MSI entry from the ARP.
I've found these links but I don't know if it's relevant:
https://stackoverflow.com/questions/17523974/how-to-uninstall-msi-using-its-product-code-in-c-sharp
Checking for successful uninstall

If you need to be admin then you need to be admin. Allowing a limited user to change areas of the system that are restricted would be a security breach.
You used the word "chain", so it looks like that InstallShield setup was a multiple-MSI install, perhaps with embedded UI that is suppressed. So it appears that the previous MSIs were installed as single-product view and it looks like they are all uninstalled, also as a single product view - they all uninstall. That was probably the intention in the first place - to make multiple MSIs appear as a single product, all installed and all uninstalled. Also, if that IS install was a chain of MSIs then surely you are going to replace them all (or upgrade them) anyway, yes? That's what Burn and BAs will do too.
Which MSI's ARP entry? It's not clear from your post which MSI, assuming you may be referring to one of the chained MSIs installed by IS. And are you sure it is an MSI entry that remains? It might be the chained product's entry that was put there by InstallShield, not an MSI entry. Certainly if your uninstall of the MSI worked its ARP entry would be removed, but may need a refresh to see that it's really gone (but that's a Windows issue). Keep in kind that chained MSI products (and often Burn too) will suppress the individual MSI ARP entries in favor of a single entry that encompasses the multiple MSIs.

Visual Studio Setup Project not removing DLL

I have a problem regarding the Visual Studio Setup Project and uninstalling an application.
This is a very basic installer, installing an ApplicationLauncher.exe C# .NET 4.0 console application and an Application.Common.dll (a dependency of the application ApplicationLauncher.exe).
The installation is a success, copying both the exe and DLL into the program files folder C:\Program Files (x86)\Company\ApplicationLauncher\.
My problem comes when uninstalling the application (through the MSI) - the uninstall seems successful, however it leaves Application.Common.dll behind, and doesn't remove it as I would expect.
I've used ProcessExplorer to make sure nothing else is using the DLL, no explorer windows are open during the uninstall.
Is this the expected functionality and do I have to create a custom action to remove this DLL? Or have I done something wrong? :S

It seems I was able to fix this issue by renaming the solution and product name of the application, I'm not sure how this fixed it, but it did.
My only thoughts here is this traversed through to the installer, where the application installed into a different folder, thus not applying the same permissions to the DLL..

It's not expected, no. It will happen if you ever done any of the following with your setup and installed it:
Marked the file Permanent.
Marked the file SharedLegacyFile true.
These are project settings, but if you set either of them and do the install it will stay behind. You can unset them in the setup project but that's too late - you've marked that component permanent or sharedlegacy on the system. If you use a brand new system, like a fresh virtual machine, reset these values if they are set and rebuild the MSI and do the install/uninstall does it still happen?

I had the same problem. Then I have tried to install and unistall my app on Windows XP and that had worked.

Renaming the ProductCode is treating the symptoms not the cause. The problem occurs when the uninstaller doesn't remove the dll. The next install will use the dll again and can't remove it on an uninstall event because it's still used by the other program.
These steps hopefully solve the problem:
Install your Software
Open CMD (with admin privileges) and run:
msiexec /x {ProductCode} /L*V "C:\CustomPath\FileName.log"
The ProductCode can be found when hitting F4 on the Setup Project
Open the log file and search for the lines that look something like this:
Disallowing uninstallation of component: {6CEC09F6-9108-7062-A692-2BCBACEE3BD8} since another client exists
Disallowing uninstallation of component: {A0A0FA84-CC0D-C5C4-1F57-169788C4482D} since another client exists
Disallowing uninstallation of component: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} since another client exists
All these components have to be removed from the registry by hand. To do this the GUID (e.g. {6CEC09F6-9108-7062-A692-2BCBACEE3BD8}) first has to be converted into a packed/compressed GUID (e.g. 6F90CEC6801926076A29B2BCCAEEB38D). I found a Website where one can run a script to do this. Find the following code on the website and replace the right side with the GUID from the log.
string inStrGUID = "{6CEC09F6-9108-7062-A692-2BCBACEE3BD8}";
Open the registry (as an administrater) and search (Edit -> Find...) for the compressed GUID (uasually it's somewhere in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\)
Delete the folder that is equal to the compressed GUID. The values inside the folder should be a path to the dll.
Once deleted select the parent folder (...\S-1-5-18\components) and hit Edit -> Find...
Repeat these steps (4-7) for all components from the log file.
It's also a good idea to delete all files still present in the original folder that weren't uninstalled.
Can one prevent this from happening?
I don't know. This really isn't that easy to reproduce. Some other post on SO have suspected the install/uninstall option in Visual Studio to be the cause of the problem but I have a different theory:
This bug might be the result of RemoveExistingProducts in InstallExecuteSequence in the Setup being executed too late and therefore not removing dlls at the right time. This bug is known for years and can be fixed by doing this. If you need help with Orca this explains how to install it.

How does the InstallAllUsers option work?

I have a C# application, and a Visual Studio (2010) Setup Project with it. In my Setup Project, I am using InstallAllUsers = True. Additionally, my application needs to launch at Startup, so a shortcut is being added to the User's Startup Folder.
So I install my application as user Bob (from a share), and then I log off and log on as user Alice. Alice gets a dialogue that says:
The feature you are trying to use is on a network resource that is unavailable.
It provides the network path from which the MSI was installed. So, basically, it's looking for the MSI on a share that Alice doesn't have access to. This is repeatedly reproducible if Alice tries to manually launch the Startup link. However, Alice can directly launch the exe from the installation location, which works fine.
I don't fully understand why it is looking for an MSI, but I guess it makes sense that an application can not be completely installed by one user for another user, so the MSI is needed to complete the installation.
But if that is the case, then I don't understand why the MSI only seems to be required when launching from the Startup link, and not from the exe directly.
My question has several parts:
Is what I am experiencing expected behaviour for the InstallAllUsers option?
If so, how can I ensure that my application is fully installed for all users?
Is it necessary to copy the msi locally, and ensure that it does not get deleted before each user has had a chance to log on?

This is happening because the shortcuts are "advertised shortcuts" hence the greyed out target box.
More info here...
http://www.advancedinstaller.com/user-guide/advertised-shortcuts.html
When an advertised shortcut is launched it validates the checks
associated with the key resources. If any is missing it will fix it by
running the installation package and installing again all information
from the .msi file.
This is why its trying to run the msi.
You can turn off advertised shortcuts by reading this article...
DISABLEADVTSHORTCUTS=1 disables all shortcuts
If its an all users install, then the shortcut will probably want to reside in the all users start menu. Win 7: C:\ProgramData\Microsoft\Windows\Start Menu.

Eric, I would recommend taking a look at the shortcut file contents. You can do this by using Powershell, and there is a SO link to help you on your way:
Editing shortcut (.lnk) properties with Powershell

How to find a Windows Forms Application's Product Code?

I need my application to uninstall itself.
Reason: It's come to my attention that my app is destroying its own files (my bad), but the user of my app doesn't understand why he needs to uninstall it and refuses to uninstall it. However, he still complains about the constant problems. And in the Terms Of Use, there is a line that says "...we reserve the right to remove the application from your computer and temporarily or permanently discontinue your use of the software."
So, I did some searching on how to uninstall a program, (which will be replaced by a new version), and came across Uninstall C# windows application from self and the accepted answer says you need a 'product code'. What exactly is that, and where can I find/get it from? I have searched for this but can't find anything.
Thank you

The productcode can be obtained from your MSI by opening with orca, the msi db editor and lookup the productcode in the Property table. Orca is part of the Windows SDK.
You can also run your msi
msi /i [your msi] -lvx* log.log
and harvest the productcode from the log.
The easiest way is by getting it from the author files of your setup as Ken White already pointed out.

You created the product code (if it exists) when you created your MSI to install your application. You need the same product code you used in the installation in order to uninstall it via Windows Installer.

I am not sure about VS 2010, but in VS2008 setup projects have a ".vdproj" project file, which can be opened with a simple text editor (like notepad). If you search for the word "ProductCode", you will find a line like
"ProductCode" = "8:{GUID}"
(the GUID is what you are looking for).