Develop Reference

Desktop applicaton not opening after installation in client system

I am currently working with visual studio 2017 with 4.6.1 .net framework. I created setup file for my desktop application the setup installs and runs perfectly in my system. The issue is that the setup installs successfully in other computers but the application not getting opened.
edit
Downloaded .net framework in client system but still same issue occurs.
edit 2
I ran a dependency scan using Dependency walker. It said there were a bunch of files the system could not find - error opening file. The system cannot find the files specified.
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
IESHIMS.DLL
Also, there was an error with modules with an x86 type found - including the setup.exe - but I am unaware how this happened. I have selected 64 wherever I saw the option listed. Please find the screenshot. If this is indeed the issue, how do I solve this?

Application Launch Problems: Here is a short version: WPF application crashes when I launch. Chattier version. Nice one from Martin Prikryl: Application does not work when installed with Inno Setup
Logs: Always check all event logs, application logs and MSI logs - if available. Just to mention it. Maybe try to attach debugger for testing as described here - provided the application gets off the ground at all. Then step through code.
The Usual Culprits: You probably just lack a runtime (example), have a bitness problem (32/64-bit) or insufficient permissions / privileges, or configuration errors (ini, xml, registry, etc...).
To summarize - torpedos, full spread below - nothing too dumb not to mention :-):
Missing Runtimes: First, always check for missing runtimes. For example: .Net, .Net Core, Java, Silverlight,
Direct X (used even for applications now), VC++ Runtime, MS-XML (legacy), etc.... Remember that they come in different versions and some can not co-exist on the box whilst others
can run side-by-side.
Error Code: Looking up error codes and exception messages.
"The Magic Number Database" - online lookup.
Checking Error Codes - several tools and approaches.
Debugging Tools: Some information on debugging tools.
Tools to debug dependency issues - ProcMon.exe, VS, Dependency Walker, etc...
COM dependency errors
Essential service debugging tools:
Event Viewer, Task Manager, Services.msc
Process Explorer, NET command, SC.exe
Windows Services Frequently Asked Questions (FAQ)
ProcMon.exe: The tool of the trade. The one-size-fits-all
tool. The bee's knees, the topper-most, the quantum leap, the cat's
pajamas (yes, it is a Top Gear Hamster allusion). It can be a challenge to use it effectively, but it is the
best general-purpose debugging tool that is free.
Quick, Rudimentary Sample
Hanselman's longer video sample
Other Ideas:
Configuration Settings?
Dev-box sins: Hard coded references? Test Servers / UAT links?
Manifests, INI files and XMLfiles?
Registry settings? HKLM / HKCU
Connection strings. See Authentication & Authorization section below as well.
Platform & Bitness? (ARM, Intel 32 / 64, etc...).
Very common to read from wrong registry hive (the classic time waster):
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MyApp\MySettings (32-bit)
HKEY_LOCAL_MACHINE\SOFTWARE\MyApp\MySettings (64-bit)
Prerequisites & Dependencies?
On the topic of dependency scanning and debugging.
Dependency Walker: Types of dependencies.
Does Fuslogvw.exe tell you anything? (.NET assembly binding failures for a .NET application). How the Runtime Locates Assemblies
Quick check: Visual Studio modules view
Missing / Broken Registration (indirect dependencies)
Missing COM, COM Interop (regasm.exe), registrationless COM (manifest based)
Calling a .NET Component from a COM Component
Calling COM Components from .NET Clients
Broken Side-By-Side Win32 Assembly Manifest (obscure, can be caused by sloppy corporate application repackaging, may strike seemingly random PCs)
GAC installation?
Two GACs exist.
GAC / WinSxS Commit Issues: GAC / WinSXS files don't get installed into the GAC until the commit phase which is after StartServices.
Permissions & Privilege? - local - ACL permissions and NT privileges?
ProcMon.exe
Resolving Permission Denied:
System.UnauthorizedAccessException while running .exe under program files
WiX after installation my exe file doesn't work by double click, only run as administrator work
Authentication / Authorization - network related
Local user, domain user, Active Directory: group membership, group policy, etc...
Launching User: User profile issues? Maybe try with another user logged on where it fails?
Authentication Mode: Windows Authentication. SQL Server Authentication, etc...
General Network & Proxy issues? (proxies, WINS, DNS and all the complexities involved in networking. UNC paths reachable?)
Licensing? (conceivably related to hardware dongles and drivers)
Security software interference? (software / hardware firewall, anti-virus, encryption tools and suites, etc...)
OS version or edition? (Windows 7 problems)
Localization? Non-English systems?
Drivers?
Hardware?
Encoding?
System corruption? (wrong time, disk errors, file and path names are too long, disk full, "wrong something")
Target Machine Nature? Virtuals? SOE? Are the target machines real machines? Test machines?
Locking / Blocking / In-Use files and registry keys?
Malware? Can cause practically anything in terms of problems.
Links:
WiX Toolset PermissionEx Problem - App Does Not Run After Installation
EXE file is not working

make sure that the 4.6.1 .net framework is installed on the client system.Because the application requires .net frame work installed on the computer

To successfully deploy an application, you must also deploy all components that are referenced by the application.View the Deployment Process
Users might need administrative permissions or similar user permissions on the computer to install bootstrapped components. For ClickOnce applications, this means that the user might need administrative permissions to install the application regardless of the security level specified by the application. After the application is installed, the user can run the application without administrative permissions.
I am assuming you and your client are running install and application run as Administrator.

Possible root cause:
System prerequisite is not meet, you should check all dependencies is ready on the target client system, or add the prerequisite to your installation guide
Privilege issues, you might copy files or change registry locally with administrator rights, but the client is not. If so, you need change files to "C:\Users{username}\AppData\Roaming" or install with administrator privilege on the client system.
In such a situation, app possibly crashed in client system:
Check your application log if any errors
Check windows Log if any errors
Dump system info using WinDbg.exe and debug it

I also faced that kind of problem before.
Just try to install another location not inside the program file of C:\ Drive. You may choose different drive or you may install in C drive also but not inside the program files.

Getting the error "The 'VFPOLEDB.1' provider is not registered on the local machine" even after installing and registering the provider

Alright, so I've got a Windows service that has a FileSystemWatcher that watches an output folder for some Visual FoxPro database files. And it leverages the VFPOLEDB.1 provider to read those files. I cannot go away from this provider because it's being used in production.
However, I've never had to support this application before so that's why my development box isn't setup for it. Here is my environment:
Windows 7 x64
Visual Studio 2005
.NET 2.0 Windows service
so, when I first started getting the error I figured I just didn't have the provider at all, and I was right. So, I downloaded and installed it from here.
I then proceeded to drop the files in the folder again, but I got the same error.
I figured because it's an x64 machine I might be experiencing problems with it getting registered since it was probably dropped into SysWOW64, and it was as I expected, so I ran this command:
regsvr32 "C:\Windows\SysWOW64\mscomct2.ocx"
and it said it was successfully registered (which means about nothing LOL) but I dropped the files in again - same error.
I have not yet rebooted my machine, and I can if somebody has a compelling reason that's the problem, but generally speaking if the assembly is registered properly with regsvr32 that's not necessary. I've worked with a ton of COM objects and never have to reboot to get to the object as long as I've registered it.
Does anybody know another step I need to perform to get this thing registered?

It is registered as it should. It is your application that is compiled for AnyCPU Platform.
In x64 operating system this produces 64bit code and 64bit code could not access 32bit drivers.
Change your Platform to x86 and you will be fine.
EDIT
Two years later there is something to add to this answer. Now with Visual Studio 2013 the cheese has been moved. The article linked explain in great details how the compiler setup defaults has been changed. The AnyCPU target CPU with Prefer 32 bit means that your application works as 32bit app also in x64bit operating systems leaving practically no-room to x64 application unless specifically required.
With this new configuration becomes also important to remember what is posted in comments below by Mark Berry. If your (now 32bit) app needs to work in a IIS 64bit environment you need to set the Application Pool with Enable 32 bit Applications

I have desktop app (Win7 x64 VS 2015) - and kept getting the same error no matter what. I changed platform target to x86, installed MSI as admin etc - did everything I could google - and no luck. What helped me is to install MSI for Everyone instead of Just me - one of the last wizard's screen in the setup.

I have the same problem.
I install the VFP Ole DB Provider in my system and resolved.
download link

use Advantage OLE DB Provider,works for 32 or 64,here is the connection string

SQL1159 Initialization error with DB2 .NET Data Provider, reason code 2

I am trying to connect to DB2 from .NET 2.0 application in my development machine running windows 7 64 bit.
I am getting this error in open method. Could not find a solution.
ExceptionType: InvalidOperationException
ExceptionMessage: SQL1159 Initialization error with DB2 .NET Data Provider, reason code 2, tokens D:.......................\bin\db2app.dll,
StackTrace: at IBM.Data.DB2.DB2ConnPool.Open(DB2Connection connection, String& szConnectionString, DB2ConnSettings& ppSettings, Object& ppConn)
at IBM.Data.DB2.DB2Connection.Open()

Learnt this from a colleauge of mine. Issue was because db2app.dll was missing in bin directory of application folder.
Copied db2app.dll and db2app64.dll from C:\Program Files\IBM\SQLLIB\BIN to bib folder of application and it worked fine.

See the "user response" at the bottom of the IBM doc for SQL1159N, which also lists the various reasons you might receive this error code:
There was a problem with your DB2 installation. If this is the first time DB2 was installed on this computer, review the install logs for any possible errors and run a repair of DB2 from the Add/Remove Programs control panel applet. The default location of the installation logs is the My Documents/DB2LOG folder of the user that performed the installation. If this does not resolve the issue please contact IBM Support and provide the reason code associated with this message along with any installation logs.

I had a 32 bit DB2 Client and I was accessing it from a Web Application hosted on IIS, using Application pool (with 'Enable 32-bit Application' set to false). In this case a
64 -bit client (db2app64.dll)
is expected while db2app.dll will throw above error.
Just FYI..
It is hard to debug this error in Visual studio as by default IIS express uses 32-bit application pool. To change it to 64-bit, one has to make changes in registry (set Use64BitIISExpress to 1) There is no inetmgr for IIS Express.

After speaking to IBM, they recommend strongly against putting IBM dlls inside the bin folder. We let IBM remotely configure our server and now all works well and we must not put the ibm*.dll into our bin folders or it will not work.

"Required permissions cannot be acquired" while debugging standalone application

I'm trying to debug a native application that uses some C# components but I'm getting a "Required permissions cannot be acquired" error when trying to start the application.
Now I did search StackOverflow and the net in general but all answers that I could find were related to ASP Web applications but the one I'm trying to debug is a standalone one.
Additional background: I'm using WinDbg to debug code that runs in a remote machine via remote terminal (in fact by using TWO remote connections since the machine in question is not reachable from my machine directly thanks to some stupid router configuration). The binaries are located on my computer and I access them via the auto drive mapping that RT does for me.
Now I did have similar issues in the past and I'm pretty sure that the code would run if I copy all the binaries to the target machine and start them from a local drive but this is something that I want to avoid.
NOTE: The code is targeting version 2.0 of the .Net Framework. The target machine does not have the configuration tool for .Net 2 installed and I gave up trying to install and make it run by hand to try to see if there is some "trust" setting that I can set to mke the code run..

Problem turned out to be a firewall issue and related to the fact that I could not reach the target machine (where the program was running) directly from my PC (where the executable files where located). I was connecting indirectly through another PC to the target machine and this was causing problems with the .Net security checks, after changing the switch/firewall so that I could connect directly I had no more problems.

Why does my .NET application crash when run from a network drive?

My .NET application fails when run from a network drive even when the very same executable runs perfectly fine from a local hard drive?
I tried checking for "Full trust" like so:
try
{
// Demand full trust permissions
PermissionSet fullTrust = new PermissionSet( PermissionState.Unrestricted );
fullTrust.Demand();
// Perform normal application logic
}
catch( SecurityException )
{
// Report that permissions were not full trust
MessageBox.Show( "This application requires full-trust security permissions to execute." );
}
However, this isn't helping, by which I mean the application starts up and the catch block is never entered. However, a debug build shows that the exception thrown is a SecurityException caused by an InheritanceDemand. Any ideas?

It indeed has to do with the fact the apps on a network location are less trusted then on your local hdd (due to the default policy of the .NET framework).
If I'm not mistaken Microsoft finally corrected this annoyance in .NET 3.5 SP1 (after a lot of developers complaining).
I google'd it: .NET Framework 3.5 SP1 Allows managed code to be launched from a network share!

Did you try Using CasPol to Fully Trust a Share?

You may have already done this, but you can use CasPol.exe to enable FullTrust for a specified network share.
For example
cd c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
CasPol.exe -m -ag 1.2 -url file:///N:/your/network/path/* FullTrust
More info here.

If this is .NET 2.0 or greater, ClickOnce was created to really help with this deployment stuff. I only deploy to network shares using that.

This is security built in by microsoft into the .net framework. It's a way of stopping malware to be run locally with full priviliges, so you cannot change this programmatically in the code.
What you need to do is increase the trust of specific assemblies. You do this in the .NET Framework Configuration (Control Panel->Administrative Tools), and has to be done on each computer.
As with any security measures, it's a pain-in-the-ass, but will help the world to be less infected etc...

All I had to do was mark the files Read Only (possibly unrelated) and give all permissions except Full Control to Authenticated Users. I was encountering this issue before I did that, when I had the network share only setup for Domain Users.
I discovered this workaround because neither the admin shares (\server\C$) nor my own PC's shares had this problem.
Edit: App is targeting .NET 3.5, no SP1 here (version 3.5.7283)