This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(185.6, 56.00000000000001%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERK%3C/text%3E%3C/svg%3E)
The application is a C# solution linked with C++ projects and I suspect this is a sticky point for publishing the application for standalone execution.
As far as I can tell none of the dependencies are missing, but I see the following errors in the Event Viewer:
Application: MyApplication.exe
Framework version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
at MyApplication.Array_Unit..ctor()
at MyApplication.Testbench..ctor()
at MyApplication.main()
Faulty application name: MyApplication.exe, version: 1.0.0.0, timestamp: 0xddad1087
Faulty module name: KERNELBASE.DLL, version: 10.0.19041.1645, timestamp 0xdfe831e6
Exception code: 0xe0434352
Fault offset: 0x0012b982
Faulting process id: 0x3634
Faulting application start time:
Faulting application path: C:\Users\NIWC\Desktop\Release\MyApplication.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report id: ab49e8ba-3960-41c1-a178-d5614194a7e9
Faulting package full name:
Faulting package-relative application ID:
I believe this implies a missing DLL or some other file dependency that KERNELBASE.dll is trying to load.
Not sure.
I have tried dependency walker tools but they just list all possible DLL dependencies resulting in a monolithic set of paths that are impossible to check.
Any help would be appreciated.
Thanks!
Russ
Does it run non-standalone?
Check the Array_Unit class. Is it C++ or C#?
Also try compiling the C# projects using 32-bit or 64-bit configuration, or uncheck the "Prefer 32-bit" compiler option.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(140.8, 78%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETS%3C/text%3E%3C/svg%3E)
Hi @Russ Kelly , welcome to Microsoft Q&A forum. Could you share the detailed information which was provided in VS Output window(set the output verbosity to Detailed and then build the project) with me to check further?(Tools > Options > Projects and Solutions > Build And Run > MSBuild project build output verbosity > Detailed)
Hi Tianyu,
After observing the detailed output of the build I don't think it would be a good idea for me to hand off that output here as the structure of the program is proprietary and it's behavior may be reverse engineered.
Can you tell me what I should be looking for, or if there's some snippet of output that I can provide for you to assist?
Russ
Yes it does run, as long as at least Visual Studio 2019 Community is installed.
The Array_Unit class is C#, which is also what the solution is.
There are three other C++ projects in the solution, with wrapper classes designed to support calls from C#
Russ
Hi Russ, does the output message show which file(s) that cannot be found, and does it show the detailed directory of the missing file(s)? If the error message shows the reasons/details of the error, please let me know.
Regards,
Tianyu
Hi Tianyu,
The errors in the Event Viewer did not provide detailed information on the directory or name of the missing file. However, I have since determined that one of the applications DLLs is referencing the following files:
MSVCP140D.dll
KERNEL32.dll
VCRUNTIME140D.dll
ucrtbased.dll
mscoree.dll
These three DLLs are apparently removed from the system when Visual Studio 2019 is un-installed:
MSVCP140D.dll
VCRUNTIME140D.dll
ucrtbased.dll
I have since attempted to restore just these DLLs after un-installing Visual Studio but the results were the same. It is possible that these DLLs also have dependencies that need to be retained for the application to run.
Another important detail is that I CAN get the application to come up on the target system without VS installed, but when I allocate a specific object at run-time (the one that depends on these DLLs) an exception is thrown.
I determined the DLL dependencies using the VS command line tool dumpbin and can now observe what DLLs are loaded at runtime by using the Windows native tool perfmon.exe.
These DLLs are the debug versions that are not available unless visual studio is installed. They are also not included in the visual c++ redistributables. If you intend an application to run without these dlls, then you must build a release version of any code that has a dependency on the visual c++ runtime and the ucrt.
OK, interesting.
The class that ultimately produces the error is a C++ class that is linked into the solution that has a C++ to C# wrapper to allow interaction with higher levels of the C# project.
So it sounds like you're saying I need to build a release version of those lower level DLLs to link into the C# project.
Is that correct?
Russ
Yes.
Excellent!
I have begun building a release version of the C++ layer in the C# solution and now see a number of build errors.
I will try to address these on my own and get back to you if I hit a road block.
Thanks!
Russ
Don't forget that the release version of the three dlls needs to be present on your target system. So you may need to also install the visual c++ redistributable (32 or 64 bit). The ucrt is a Windows system component so you should not need to install anything for it.
OK, thanks for the tip.
Hey, I need to add a third party file to my published application, but I can't seem to find a way to do that. It is a binary file but not an executable. The compiler will allow me to "add" it to the project, but not publish it with the application.
Was your dll problem resolved?
Not actually sure, because the object is still failing to come up but it depends on a third party file it must read to load.
Not sure of a good way to know what directory it should be put in or how to get it there with the publish feature.
Maybe this will help
OK, that puts the file in the Publish directory but when I execute the setup.exe and install the app standalone I don't see where the file is "installed" by setup.
I discovered a subdirectory deep in the bowels of the c:\Users\User1\AppData\local\apps\2.0 where the executable and DLL files are installed, but the third party file is not there.
The guidance on programmatically accessing data files installed by click once is here
accessing-local-and-remote-data-in-clickonce-applications
OK, figured out the third party file installation with the application, and I've completed creating a Release version that I can install via the setup.exe in the Publish directory. However, after installing and discovering the directory where the files are installed I discovered that the original DLL problem still exists. Below is a sanitized version of an exception I get when I try to load the DLL:
C:\Users\MyUser\AppData\Local\Apps\2.0\YN8JWDKQ.EDH\ODXLX1P8.9KY\tabs..tion_0000000000000000_0001.0000_f10b033ab66e7b12>dumpbin /dependents MyInterface_Wrapper.dll
Microsoft (R) COFF/PE Dumper Version 14.29.30145.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file MyInterface_Wrapper.dll
File Type: DLL
Image has the following dependencies:
MSVCP140D.dll
VCRUNTIME140D.dll
ucrtbased.dll
KERNEL32.dll
mscoree.dll
Summary
2000 .data
1000 .msvcjmc
2A000 .rdata
3000 .reloc
1000 .rsrc
38000 .text
Looks like the Release version of the DLL is still reflecting a need for the three supporting DLLs that you have said are for debug only.
Can you explain that?
Your configuraton/project settings are probably incorrect with respect to the C++ DLLs.
All of the C++ projects are built with the Release solution configuration.
What else needs to be set?
C++ projects have independent property settings for the various Configuration/Platform combinations.
Check the Configuration Manager -
Check the configuration for all platforms.
Check the Project Properties -
Check for all platforms
OK, the Code Generation --> Runtime Library settings are already set as you've illustrated in the C++ projects, except the Platform is "Active(Win32)".
The C# project doesn't have the same kind of Property Page but the C# project Platform is "Active(Any CPU)" with Platform Target set to "Prefer 32-bit".
The InterfaceWrapper.dll still lists dependencies as the 5 DLLs previously mentioned, and even with Visual Studio 2019 not installed I can see those DLLs living in the C:\Windows\System32 directory, but not in C:\Windows\SysWOW64.
Is it possible there is a platform conflict between the C++ and C# projects?
Why are you showing me a Debug Active Solution Configuration? You're supposed to be working with Release!!!
Lets be sure. Post screenshots of everything that you have checked so I can see it for myself.
Sorry, previous post included a mockup of the Configuration Manger and the wrong Active solution configuration was displayed. This is a more accurate image. (Note I've "sanitized" the image so the true project names would be obfuscated).
Goodness, your problem is staring you right in the face!!! Your "Release" configuration is actually building Debug projects. LOOK AT THE INDIVIDUAL PROJECT CONFIGURATIONS.
Another mockup error. The actual screen is on a standalone machine.
Sorry to be so frustrating.
The configuration settings in the actual screen are in fact "Release".
Trying to communicate without revealing proprietary names and information and I'm bungling it.
If you won't show unedited screenshots of actual project settings I can't help you any further.
This should be better.
And what about the settings for all the individual projects? Let's see them all.
OK, I'll work on that and get back to you.
Would it be easiest just to see the vcxproj, vcxproj.filters, and vcxproj.user files?
Taking snapshots of each screen would be cumbersome for both of us.
I'd rather see the settings that you say you are working with through the user interface (i.e., screenshots). I saw 3 C++ projects in your configuration manager. 3 screenshots shouldn't be a burden.
OK, the Configuration Manger screen is the same for all four projects so I'm guessing you want to see the property page for each C++ project and show the Code Generation settings, as in your previous screen shot.
Is that correct?
That's correct.
OK, here are the snapshots:
Based on the information provided I can see no reason why VS2019 should build C++ DLLs that need the debug versions of the vc++ runtime and the ucrt.
Another possibility is that the DLLs that are being deployed are not the ones that VS2019 is creating with the settings shown. At a minimum I suggest you compare dates, file sizes, version numbers, etc. between what VS2019 is creating in the directory specified as $(TargetDir) in the C++ projects and what is deployed by your click once installer. If you run dumpbin on the DLLs in the $(TargetDir) directories does it show the release versions as dependencies?
OK, I'll do that.
Thanks!
So when I build the Interface_Wrapper.dll in Release mode it puts the DLL in the projects Release directory and it is 266K.
When I do a Publish on the main project (which is C#) it puts the results in the solution level Publish directory with an "Application File" subdirectory that contains directories for all of the published versions.
The most recent directory has an Interface_Wrapper.dll.deploy file which is 401K.
When I install via the Publish/setup.exe it populates a directory under the user's AppData directory and I see it contains the executable and an Interface_Wrapper.dll that is also 401K.
Both the Interface_Wrapper.dll.deploy and the Interface_Wrapper.dll are identical files. Why are they larger than the DLL in the Release Directory?
Because they're the wrong files. Did you do as I suggested and run dumpbin on the DLLs that are placed in the $(TargetDir) folders?
OK, it's pretty clear now what's happening, though I'm still not sure why.
The Interface_Wrapper.dll from the debug directory is the one being published instead of the one from the Release directory.
When I replace the installed version with the Release version the application executes successfully.
Trying to look for a setting that might cause this even when the configuration is set to "Release".
One way you can end up with this problem is if the C# project reference to the C++ DLL was made by selecting a file using "Browse" instead of selecting the C++ project. If the specific file used to add a reference was a debug version then that is what will be published.
Yes!
That was the problem. I was looking for the issue in the Property Pages, but what I had done is add a reference in the C# project to the DLL directly, and it was pointing to the one in the Debug directory.
I figured it was probably something simple, but it's finding it that was the problem.
Thanks so much for your patience.
I know you have better things to do that babysit wayward developers.
You're welcome.