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.
Related
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
I have developed a C# winform application in Visual Studio 2010 that connects to a Access 2010 *.accdb database. It works fine on my pc but when I install it on another, It throws the error "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."
I tried to compile it to x86, as advised, without any succes.
Any help/advice is appreciated, I think that I should include this driver as part of my clickOnce install. If so, how do I do so? (It does not appear as an option in the checklist of requirements, in VS Properties > Publish > Previous requirements)
You will have to use a more advanced method of deploying the necessary driver - ClickOnce won't do it by itself as far as I know. I also don't think it's as simple as a single DLL. The driver needs to register with the system etc.
There is a big issue with the Access drivers because of the way they are set up. If the user has Microsoft Office with Access installed, they will already have the ACE driver. The problem is, if they have 32 bit Access installed on a 64 bit machine, your 64 bit application will not be able to talk to Access because the machine only has a 32 bit driver, and you cannot install both.
If none of your users have Microsoft Office with Access, then you should be able to deploy the standalone driver installer for 32/64 bit as necessary with each computer.
It is possible to include arbitrary assemblies and files as part of your ClickOnce install by adding them to the project and changing their file type to Content. They will then appear in the list of Application Files.
Note that you'll get a warning from Visual Studio if you do this, but it can be safely ignored.
You can build an msi instead of oneclick and create a custom action that would install ace driver in quiet mode. Since its an executable you can just run it in a process object
I have an application which does not read ANY files from the local disk or does not try to write anything.
It runs perfectly on the local filesystem, but it needs to run on a few 100 workstations, so I put it on a share on a Win2003 server.
But when I try to start it on a XP workstation from the UNC:
system.io.fileloadexception
What can be the issue here?
The issue is that the XP machine is likely running an earlier version of .Net 2.0. Up until 3.5 SP1 it was a violation of CLR security policies to run a .Net application from an UNC share. To do so you must tweak the CAS (Code Access Security) policy on the local machine. Starting with 3.5SP1 this requirement was removed.
More Details:
http://geekswithblogs.net/robz/archive/2008/08/19/.net-framework-3.5-sp1-no-more-need-for-caspol-on.aspx
Only applications on the local file system have full trust to run. Try following the steps on this site:
http://dotnetdud.blogspot.com/2009/01/how-to-give-file-share-fulltrust.html
.Net code access security might be one of reasons. You can adjust it in thru control panel and change the settings for "Local intranet" zone. The best solution is to create a custom policy, however.
it is because of limited permissions. as far as i remember, if you go to explorer and find that exe, right click on it, you will see tab for extending permissions for app.
I am developing on a 64bit version of Windows 7, running MOSS (SharePoint), this is my dev machine.
Now when I deploy my web service app to a test server Windows 2003 32bit (no Sharepoint installed) I get this error.
Could not load file or assembly 'Microsoft.SharePoint.Library, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified
The DLL has clearly been copied to the bin directory (Microsoft.Sharepoint.dll).
Any ideas?
If you are using sharepoint dll's it will only work on a machine with sharepoint installed.
Even if you managed to hack it and get it to work, you would probably be breaking a license agreement.
There is a way to load Sharepoint libraries in a development console with windows XP, Vista or Seven.
See here: http://fernandof.wordpress.com/2008/02/11/how-to-install-the-sharepoint-2007-vs-2005-extensions-on-a-workstation/
[O]pen the regedit and create the following keys and the string value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0]
"Sharepoint"="Installed"
That’s it! You have fooled the installer into running on a
workstation. Easy. I also recommend adding the core SharePoint
assemblies into the [GAC] using gacutil. Those assemblies can be found
by default in any [SharePoint] machine under the folder: C:\Program
Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI.
This is almost certainly a dependency issue. The DLL is dependent on another DLL which isn't in the GAC or on the probing path. The two tools you need to figure this out are FUSLOGVW.EXE and Process Monitor
Fusion Log viewer will allow you to look at assembly bind successes and failures as your application loads. It's part of the Windows SDK.
http://msdn.microsoft.com/en-us/library/e74a18c4(VS.71).aspx
FUSLOGVW needs admin privs to run correctly.
If that doesn't work another tactic is to use Process monitor to look at which files aren't getting loaded and which folders are being searched.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
However. Without SharePoint installed I wouldn't expect this to work.
Ade
From MSDN:
"The CI build environment for the Training Management application does not perform any tests that require a live instance of SharePoint. All the unit tests use mocks that replace the actual SharePoint instance and services. Building the code and running the unit tests only requires that the following SharePoint assemblies are installed on the CI build server:
Microsoft.SharePoint
Microsoft.SharePoint.Security
Microsoft.SharePoint.WorkflowActions
Supporting referenced assemblies"
http://msdn.microsoft.com/en-us/library/ff647619.aspx
Don't mix 64-bit and 32-bit for dev / testing / production. This will never work reliably if at all.
Well what about other dlls referenced by the Sharepoint dll? With long dependency chains it can be quite difficult to diagnose these sort of problems. In such situations I find the fusion log viewer extremely useful. It is a part of framework SDK - open the SDK Command prompt and type fuslogvw. It is pretty obvious from there
We have an application that is distribute to a varity of customers. Sometime it is installed on a network share. Usually we can give that application access with caspol.exe and grant the LocalIntranet Zone FullTrust. Sometimes the customers admins do not manage to grant that application access due to some network settings.
When we launch the exe it opens for a short time and appears in the Client Task Manager and disappears silently... now the question is there a tool which gives me some debugging or tracing details on that. Is there a tool to debug security issues like that... I assueme that this happens before any of my code is executed... and I do not see anything in the event trace neither on the client nor on the server...
Any ideas?
Can I recommend - perhaps look at ClickOnce - a click-once application can be hosted on a network share, but has much better security deployment factors. You just run the .application rather than the .exe (VS2005 and VS2008 have all the tools you need to publish a ClickOnce application trivially).
Also - in one of the recent service packs (perhaps with 3.5 SP1), I believe that mapped shares get more priveleges - so \\foo\bar\my.exe would still error, but f:\my.exe (to the same location) should work.
We're having similar issues with our applications which are usually placed on a network share. We're solving this issue by:
signing and timestamping all application components with Microsoft Authenticode certificate issued by Thawte.
deploying msi package containing security policy granting full trust to applications signed by our certificate.
If your company will not / cannot buy code signing cert, you can install a CA somewhere and issue cert for that purpose only ( I think it will work altough this cert will not resolve to trusted root. )
The other option, with a lot more hassle would be to strong-sign all assemblies, and grant full trust to all assemblies signed with that key.
Both approaches result in performing procedure once per workstation ( updated applications will still work ). I think it can even be propagated throughout the enterprise somehow, but never did that and don't know details.