All,
I have a WPF application built upon SQLite database and user/application Configuration settings. The application builds and runs fine in development environment. I created a Setup and Deployment project, added the "Project output" of above said application and then proceeded to create a setup. The pre-requisites and the .NET Framework versions are same in the Application and in the setup project:
.NET Framework 3.5 Client Profile
MS Visual Basic Powerpacks 10.0.0
Windows Installer 3.1
But when I move it onto another PC with identical .NET Framework installed (but without the development environment), the application does not start. It gives a "has encountered a problem and needs to close" Error. I found that this would mean a uncaught exception in the application. So, I tried to comment out parts of the application that did not have them handled and left all but a single window to display (the Main window that does nothing) but yet the application fails. I begin to suspect that the problem could be that the dependancies are not handled for the app start. Here is what I did with them:
SQLite needed a DLL that is automatically added to the "Detected Dependencies" It gets copied to the Application Directory
SQLite databases are added manually to the project and they are copied to the Application Directory
The Application.exe.config files are NOT copied. I am not sure where to put them
At this point, I would like to know how I can find out the root-cause for the problem. I tried running another simple app with a single window (and no functionality) and it works on the target machine. TIA
If you think the problem lies in the dependencies then it might be worth having a look at the "Assembly Binding Log Viewer" (i.e. fuslogvw.exe). This tool should be able to tell you exactly which assemblies were requested and how the requests were satisfied, or not satisfied. The catch is that this only works for managed assemblies.
If however you want to find out what the unhandled exception is then you could wrap a try .. catch around the application entry point. The catch in WPF is that this is generated by the compiler / Visual Studio so you can't normally change it. If you do want to change it, say to put a try .. catch around it then you need to (example taken from http://www.infosysblogs.com/microsoft/2008/09/how_to_write_custom_main_metho.html):
Find the App.xaml and App.xaml.cs files
Open the property page for App.xaml and change the build action to 'Page'
In App.xaml.cs add a Main() method which should look like:
[STAThread]
public static void Main()
{
var app = new App();
app.InitializeComponent();
app.Run();
}
If you wrap a try .. catch around the entire method body then you could write what ever the error information is to a text file. Hopefully that will help you find out what is wrong.
===== EDIT =====
If the unhandled exception is not being caught by the try .. catch construct then it can be a binder problem. Because the JIT compiler compiles methods on a as-needed basis it may help to move nearly all code out of the entry method. For example:
<!-- language: lang-cs -->
[STAThread]
public static void Main()
{
try
{
MyMethod();
}
catch(Exception e)
{
// ... Write to file here
}
}
private static void MyMethod()
{
// .. Do actual work here
}
By doing this you make sure that you are inside the try .. catch construct before the run-time tries to locate the right assemblies etc. However note that there are some exceptions that can't be caught (OutOfMemoryException, StackOverflowException and some others).
Have you considered using the ClickOnce deployment option for your application?
As you can see from this SO question it should be possible to bundle your SQLite DB with a ClickOnce application. You would get other benefits (if you are interested) such as automatic updates.
The problem also occurs if you changed the namespace of App.xaml.cs, but not of App.xaml. The moment you add the code above, you will know, since the InitializeComponent() call will not compile.
Related
I have created a small program in C# WinForms that runs fine when I start it in Visual Studio 2017. But when I build the solution and double click the .exe, nothing happens, no screen appears, even the task manager doesn't see it. No errors. It's like it doesn't do anything! My only guess is that I built it wrong because I used Nuget to install newtonsofts JSON.NET in the solution. Do I need to do anything differently or should just building the solution work?
[solved]
today i learned the difference between the bin and obj folder, thanks to everyone for helping
Based on your comment:
it is in the obj/debug folder of the project
It sounds like you're running the wrong .exe. The obj folder is used for temporary/misc. files from the build process (see What is obj folder generated for?).
Instead, you want to run the exe within bin\Debug, if "Debug" is the configuration you're building for. You can see which configuration at the top of VS.
Like others have also mentioned, make sure that Newtonsoft.Json.dll is being copied to that output directory as well. Programs and their dependencies need to be together, generally speaking. Otherwise, your exe will not know where to find the JSON code it needs to function.
99% of the time, you should pretend the obj directory isn't even there.
If that still isn't pointing you in the right direction, run the app from a command window. Any exception should get printed to it and the window will remain open for you to examine (and this has the benefit of not needing any additional logging or exception handling code to see this error).
For example, I wrote up a bad application that get a NullReferenceException in a method called Test that is called from Main. As you can see, the stacktrace is easily visible, even though my app has crashed (credit to ColinM for bringing this up originally).
I believe that there's a problem with the startup module. Follow the steps below
Open your Solution in visual studio
Double click on properties
Select output type to Windows Application
Make sure to set the startup object as follows
I hope it helps
I think there is only one reason
There is a command line argument predefined in Visual Studio. Your application uses this argument to be executed, without it, it closes itself too quickly and you even can't see your application opened.
Right click on your project in VS -> Properties -> Debug and see if there is a value in command line arguments
exe and their supporting files should be in the bin folder. Do not copy only exe from bin folder and try to run it. It is a good idea to write some exception code to get the detail.
For future reference, yet another reason (that I have experienced) can be
System.Diagnostics.Debug.Assert();
statements. In my case, the program executed normally when started from VS but when I run it by clicking its .exe (created in the Debug Mode) then it hung/freezed. No exceptions, no printed logs. Frustrating. Then I checked the Windows Event Viewer (Our true friend). It explicitly displayed the problem and the culprit was a Debug.Assert() statement.
The lesson learned again: Check
Windows Event Viewer > Windows Logs > Application
especially when your app hangs/freezes/deadlocks or when no app logs are available.
I am using Topshelf to create a Windows service which uses the chrome Selenium driver to manipulate and parse various webpages.
While the service code runs fine from a normal (NetCore2) console test application, there's a problem when it runs under the Win32 console app that Topshelf requires.
Unfortunately, I haven't been able to figure out how to debug into the underlying service code. The VS2017 debugger appears to be attached to the Topshelf console app, but won't let me step into the underlying service code, which is in a separate NetStandard2 class library. Specifically, when I come to this line in the Topshelf console app:
var scanEntry = _scanner.Run();
where _scanner is an instance of the object that does the actual scanning, I can't step into the code (i.e., F11 just steps over the line).
I tried inserting the following line into the class library scanning code:
System.Diagnostics.Debugger.Launch();
but it doesn't do anything; the code just keeps merrily executing along.
I suspect this is related to the fact that the scanning code is running in a separate process that Topshelf launches. But I haven't been able to figure out how to identify it through Visual Studio's Attach to Process mechanism.
Pointers on how to debug the underlying service code when it's running under Topshelf would be much appreciated.
Additional Info
When I tried stopping on that _scanner.Run() line, and using the context menu to single step into the class library code (rather than using F11), I got prompted to turn off Just My Code, which I did. The VS debugger then tried to step into the class library code, but complained that it couldn't find the library's symbol file (*.pdb).
Which is really weird, because a symbol file with that name exists in the bin folder for the Topshelf console app.
I tried manually opening the pdb file from the bin folder, but got an error message that "A matching symbol file was not found in this folder".
Is this related to trying to debug a NetStandard2 class library from within a plain old Net console app?
Okay, turns out the problem was related to debugging a mixed NetStandard and NetOriginal code base...
NetStandard class libraries, by default, do not generate debug symbol information usable by NetOriginal apps. You have to go into Project Properties -> Build -> Advanced and change the type of debug information being generated from Portable to Full.
Once I made this change I was able to step into the class library code as per usual.
I found this at a matching symbol file was not found in this folder
I have an asp.net web app, and I have added some related class projects to my solution file. When I run the web app, I want to break and step through the code in the class (when a class is referenced).
I don't get an error messages. The code in the class project just does not kick in.
I have searched and read this post Debugging a Class Library but no luck.
How do I get that to work?
Can you try to stop the ASP.NET process? I usually have this problem when the asp.net service is still running, and I compile (by asp.net service I mean the icon that appears near computer clock). Try to close that, recompile, then run.
Are you sure you have <compilation debug="true"/> set in your web.config file? Are the classes in the same assembly as the rest of the application?
edit: The only other thing I can suggest is stop IIS and/or all instances of the vs development server, clean the project, rebuild, and give it another shot. Also be sure there is only one web.config and you aren't running in release against Web.Release.config or something.
This sometimes happens. Check Debug>Modules to see if there is your dll loaded. It seems that VS debugger doesn't have .pdb file available. Clear Temporary ASP.NET Files in your .NET folder, Clean/Rebuild and try debug again.
Also do not forget to run VS as Administrator. Try to Attach to process instead of F5.
You can call in your code this function, and the debugger will pop-up
System.Diagnostics.Debugger.Launch();
alternative you can call the Debug.Fail("Stop me to see what next");
I've been working on a simple project that uses some common .NET classes, isolated storage, some resources and no external libraries.
Somehow the EXE generated (either in debug or release mode) no longer runs (stops working as soon as it's opened) without giving any details or displaying any exceptions.
It runs normally in visual studio, and there's a .application in the same folder that when clicked starts in install process.
I'm not interested in installation files, I just want it to be the way it was: running an EXE (it's easier to get testers when all you have to do is running it).
I have previous versions of the program, and all of them run normally through the EXE's.
I don't recall changing anything regarding framework, deployment or build. I revised it and there's nothing changed apart from using new objects from the .NET framework.
--[Update]--
Just checked the event viewer. Event data "not available" and answer "not available".
This is a classic example of when a personal version control system would have helped. It would have automatically kept every version of your code including the one right before you made the change that messed up your exe.
Anyway to fix your issue comment out the majority of the code untill it atleast runs. Add a simple output statement just to make sure it is doing something. Then slowly add back in more code.
I suggest you to run your exe file in a consol (cmd.exe) to see if your application displays errors or exceptions in it.
Check the <YourAppName>.Exe.Config file.
Probably it is not well-formed Xml.
I'd start with removing the setup project from the solution, rebuilding then run it in debug mode.
I'm updating an old mobile device application for better flexibility. I had basically added the ability to configure the address of our SQL server in the case that we want to use our test server as opposed to our production server. I don't think this is causing the problem, but I wanted to state it. I also upgraded the project from a VS 2003 project to a VS 2005 project.
The issue I am having is that when I try to run the program in the VS emulator for Pocket PC, I get an error. It occurs after our "main menu" form loads and the user selects the next form to load. The form is initialized without issue, but when we try to run the .ShowDialog() method, it throws a System.MissingMethodException.
I don't have a lot of experience with the Compact Framework and really have no idea where to start looking for problems. I stepped the debugger through the entire initializing process for the new form and it ran without issue. But, again, when we come to the ShowDialog call, it throws the error.
Any ideas in where to start looking or known issues would be greatly appreciated.
I'm usually getting MissingMethodException for this reason:
I've got at least two files in my project, for instance an .exe file and a .dll file
I make changes to the .dll file's source code, and recompile
VS says it deploys the new .dll file to the device, but indeed it does not (it keeps the old file)
The .exe starts up fine, but when it starts accessing the .dll file the application throws a MissingMethodException, because it can't find the methods in the old dll file.
Fix: Delete the entire application directory from the device and redeploy.
I should have added this long ago. The answer ended up being that the incorrect version of .NET was installed on the Mobile Device.
A possible issue that can cause this situation is that the DLL is not being updated when deployed. It can be caused by the DLL in question being a dependency for more than one executable.
For example let's say executable A is running on the device and it is dependent on the DLL's method callA. You are trying to debug executable B which is also dependent on the DLL but on the method callB that you just added. When Visual Studio goes to deploy the DLL with callB in it, it is unable to do so because executable A is still using it. Visual Studio does not tell you that it was not successful in deploying the DLL. (Liar VS! ;)
To fix it, kill all the executables that depend on the DLL and then deploy it.
#Felix Alcala - You got an up vote from me. I would add this as a comment to your fix because it is directly related. Alas, I did not have the rep to do so. But, I want this answer to be public because I found it helpful
Start looking in the ShowDialog method itself. The error is slightly misleading - it's not ShowDialog which it can't find, but the JIT compiler is probably trying to compile ShowDialog, and throwing that exception (because ShowDialog is trying to call something it can't find). If ShowDialog is in a different assembly, then there may be something static that can't be initialized, which could similarly cause this - but start out looking in ShowDialog itself.
Because of this, one trick to finding the problem (if it isn't obvisou) is to reduce the code in ShowDialog until you find the line causing the problem. I'd start out commenting ALL the code, to confirm my hypothesis. If you no longer get the exception, try uncommenting about half of the remaining code at a time, etc.
You can get this exception when you try to use a regular WinForm class from a compact project.