The application is a form application and it is too complicated. It is mostly used to connect to a database with an user interface. It also uses third party dlls.
I copied my VS C# application`s bin folder to my desktop.
"C:\Users\asd\Desktop\bin"
After that, I made some changes in my solution and building it, I again copied the application`s bin file under C:\;
"C:\bin"
Now when I run "C:\Users\asd\Desktop\bin\Debug\LIVE.exe" and let it remain open I can`t run "C:\bin\Debug\LIVE.exe". There is no error when I try to open the second .exe file. It simply does nothing.
I want both of the applications to be open at the same time.
Depending on the application, there are ways to prevent execution of a second instance (I have actually implemented the described behaviour in production code) so check the production specs of the application to see if that's a desired behaviour on client machines.
Because it's using a database connection and third party DLLs, there may be other specific limitations in place preventing proper execution, so check whether any exceptions are being cuaght by hooking into the FirstChanceException (WARNING: Never use this code outside a debug context!)
#if DEBUG
static Program()
{
AppDomain.CurrentDomain.FirstChanceException += (sender, e) => { };
}
#endif
Insert this into your Program class, or whichever class houses the Main method (and rename it if it's not Program of course) and then breakpoint the opening of the handler - this will often catch lots of exceptions you're better off not worrying about, but it may also clue you in if there is a problem keeping your code from starting.
As always, make sure to run this from within VS's Debug, so as to see any exceptions as they occur.
Related
I have a command line utility app designed for making server backups. I've also got a GUI app that gives access to various maintenance functions, including the ability to make server backups. Previously, this app duplicated the backup code, which was causing consistency and maintainability issues. I'm in the process of refactoring the GUI app to reference the command line app and call its backup methods instead, in the name of code reuse.
I've just run into a problem, though - the command line app has a config file, read using ConfigurationManager.AppSettings. When it's called directly, that works fine. When it's called as a reference from the GUI app, though, it tries to read the GUI app's config file instead, as the executing assembly, and throws an error when it can't find the values it expects.
How can I force the code to always read the command line app's config file, even when it's not actually the executing assembly?
Just set AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", path);
I have a C# application that loads fine on my development machine but fails to even start on Win2008 machine.
Checked Frameworks and they match up, Net 4.0
I immediately suspected the problem was arising from references to specific files that I was reading from and sure enough, using some test code I narrowed it down to a single line.
public static string[] salesArray = (File.ReadAllLines("sales.txt").ToArray());
If I comment out the above line, the test app starts, if I leave it in, it fails. Any ideas?
I am copying the Debug directory to the second machine (sales.txt) within it.
This is the entire code. The app does nothing but open a blank window.
namespace testServer
{
public partial class Form1 : Form
{
public static string[] salesArray = (File.ReadAllLines("sales.txt").ToArray());
public Form1()
{
InitializeComponent();
}
}
}
Two potential issues jump out:
1) The current working directory of the app isn't what you think it is:
If you can print/show this, you would know for sure.
http://msdn.microsoft.com/en-us/library/system.io.directory.getcurrentdirectory.aspx
Because you are specifying a relative path, the current working directory is what the file is being resolved against.
2) Perhaps permissions. You might right-click, 'Run as administrator' as a quick check into that theory.
You should use a better mechanism to find that file, and check for its existence (ie: File.Exists) prior to opening it.
This will also let you report to the user if there is a problem, such as the file not existing where you expect it to be.
Put an exception handler around the code. You can get the error message and can handle the failure gracefully.
It should handle all errors (file not found, file in use, permission errors, etc.).
I'm a Silverlight/ASP.NET developer trying to write my first Windows Forms application to run in the background on a server, populating our database. Eventually would like this to be a Windows service, but it's not required initially.
I need to create a batch file to execute 5 instances of this application, passing in the URL to 5 RESTful endpoints. So I published my app, which created a setup.exe. After installing it, I have an item that points to
C:\Users\mi2dev\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft\, with a .appref-ms file.
I'm not sure at this point what to do. Running:
"C:\Users\mi2dev\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft\StreamingApp.appref-ms" -"http://www.myURL.com" throws up a command window briefly, but the app doesn't run, data doesn't populate in DB.
What am I missing here?
since your application is in .exe format. And make your winform accepts command line arguments (check the main method) also make your Form ctor accepts params too. Then just launch it via cmd line just as you would other command, but here only to navigate to that dir where file exists.
In case of batch, use start command followed by program name and then arguments
It's hard to understand what is happening inside your application. You need to debug to understand what is going on there when it receives given parameters.
So I would suggest to debug an EXE. For this go to your EXE project properties, select DEBUG tab in CommandLineArguments insert your parameter string.
Run it in DEBUG and hopefully you will figure out a problem.
If after debugging it's not yet clear why it behaves in that way, come back to SO :)
Silvi if you plan to use your windows forms application from a batch file and you imagine the applicationm will behave differently in such mode than when opened witha double click, the usual approach is to parse the command line (arguments, also available in the main method as parameter) and to avoid loading the UI at all.
in fact if you have written your application properly the UI only managed the UI and does not contain the whole logic of database manipulation and data transformation.
what you could do is check inside the Main method if there are command line parameters and if you detect any of the special ones you have definded you really avoid to even call Application.Run(new Form1(...)); and start working in batch mode without user interface.
the same logic you want to use in batch mode or in UI mode can be wrapped in helper classes (often also called business managers or business logic... it depends), so that you do not have code duplication but simply UI or batch will call those classes nicely.
I have a SharePoint DLL that does some licensing things and as part of the code it uses an external C++ DLL to get the serial number of the hardisk.
When I run this application on Windows Server 2003 it works fine, but on Windows Server 2008 the whole site (loaded on load) crashes and resets continually. This is not Windows Server 2008 R2 and is the same in 64 or 32 bits.
If I put a Debugger.Break before the DLL execution then I see the code get to the point of the break and then never come back into the DLL again. I do get some debug assertion warnings from within the function, again only in Windows Server 2008, but I'm not sure this is related.
I created a console application that runs the C# DLL, which in turn loads the C++ DLL, and this works perfectly on Windows Server 2008 (although it does show the assertion errors, but I have suppressed these now).
The assertion errors are not in my code but within ICtypes.c, and not something I can debug.
If I put a breakpoint in the DLL it is never hit and the compiler says:
"step in: Stepping over non user code"
If I try to debug into the DLL using Visual Studio.
I have tried wrapping the code used to call the DLL in:
SPSecurity.RunWithElevatedPrivileges(delegate()
But this also does not help.
I have the source code for this DLL so that is not a problem.
If I delete the DLL from the directory I get an error about a missing DLL. If I replace it, back to no error or warning just a complete failure.
If I replace this code with a hardcoded string the whole application works fine.
Any advice would be much appreciated, I can't understand why it works as a console application, yet not when run by SharePoint. This is with the same user account, on the same machine...
This is the code used to call the DLL:
[DllImport("idDll.dll", EntryPoint = "GetMachineId", SetLastError = true)]
extern static string GetComponentId([MarshalAs(UnmanagedType.LPStr)]String s);
public static string GetComponentId()
{
Debugger.Break();
if (_machine == string.Empty)
{
string temp = "";
id= ComponentId.GetComponentId(temp);
}
return id;
}
This could be security related:
An important point is that it works in a console app.
In a console app RunWithElevatedPrivileges has no effect since it emulates the app pool user for your worker process, a user that should have no special rights on the box itself.
In contrast a console app runs in context of the logged in user.
Try emulating a user with rights like when you run the console application specified here (with Undo() inside try/finally mind you!). When obtaining the token you can create an SPUserToken and establish site context using the SPSite constructor that takes a GUID and a SPUserToken
Theres several examples out there documenting this approach, here for example.
EDIT: oh and the reason it worked on 2003 could be that your app pool account had way too many rights ;-)
Why not use WMI to get the serial number of hard disk, thus avoids execution of unmanaged code. See this sample How to Retrieve the REAL Hard Drive Serial Number
That non-deterministic crashing behavior is often seen with memory overwrites/corruption; sometimes it matters (crash), sometimes you get lucky.
You might want to check into getting a crash dump and analyze it with WindDbg. Since you have the source you could re-build it with the various stack, heap memory protection and warning systems enabled (depending on your compiler) and see what you get.
I'd find out if it is a User Account Control related problem, you can try to disable it.
2003 doesn't have UAC.
Your app pool account might not have the right to retrieve this information?
In visual studio, go into the properties of your executable assembly, and under the debug tab, check the enable debugging unmanaged code option.
If the method your are importing belongs to a class, you need to add the mangled C++ name (e.g. 2#MyClass#MyMethod?zii) as an entry point to the DllImport attribute (run depends on the native DLL to get it).
You do not need C++ for that: http://www.codeproject.com/KB/cs/hard_disk_serialno.aspx
If i put a breakpoint in the DLL it is
never hit and the compiler says :
"step in: Stepping over non user code"
That's the debugger, not the compiler, and if you configured it properly it wouldn't do that. Look for the options calls "Use native debugging" and "Just my code". The first one should be on and the second one off.
This problem may happen due to one of the problems listed below.
the web part may not have the right permissions to call the DLL or
you may not have set the appropriate trust level for your SharePoint site.
For the permission you can use impersonation and for the trust level below site can help you.
http://msdn.microsoft.com/en-us/library/dd583158(office.11).aspx
I made a new C++ DLL from scratch which works fine when referenced as a console application on Windows Server 2003 and Windows Server 2008, but as soon as I reference it from the DLL in SharePoint the same things happens and it won't run.
It does find the DLL, but I think it has no permissions to execute it, even if I put it into the My Documents section and reference it directly!
I have some UI application that lives in the user's task bar that is written in C#. The EXE for the tool is checked in to our source control system on a number of projects that use it so we are able to update the version they run with by checking in updated EXE.
The problem is that when the users get the latest revision of the exe, the program is often running, and the sync fails on their machine. I want to fix it so the program doesn't lock the exe and any dependent DLL's when it runs so they can sync without having to shut down the program.
Currently, I have a program that takes an executable as a parameter and will launch it from memory by reading the assembly contents into memory ahead of time. Unfortunetly, this totally fails when it comes to the DLL's that the program requires.
The code I have right now looks something like this:
public class ExecuteFromMemory
{
public static void Main(string[] args)
{
//Figure out the name of the EXE to launch and the arguments to forward to it
string fileName = args[0];
string[] realArgs = new string[args.Length - 1];
Array.Copy(args, 1, realArgs, 0, args.Length - 1);
//Read the assembly from the disk
byte[] binary = File.ReadAllBytes(fileName);
//Execute the loaded assembly using reflection
Assembly memoryAssembly = null;
try
{
memoryAssembly = Assembly.Load(binary);
}
catch (Exception ex)
{
//Print error message and exit
}
MethodInfo method = memoryAssembly.EntryPoint;
if (method != null && method.IsStatic)
{
try
{
method.Invoke(null, new object[] { realArgs });
}
catch(Exception ex)
{
//Print error message and exit
}
}
else
{
//Print error message and exit
}
}
}
My question is, am I doing something totally stupid? Is there a better way to handle this? If not, what should I do to support handling external dependencies?
For example, the above code fails to load any dependent files if you try to run 'Foo.exe' that uses functions from 'Bar.dll', the 'Foo.exe' will be overwriteable, but 'Bar.dll' is still locked and can't be overwritten.
I tried getting the list of referenced assemblies from the 'GetReferencedAssemblies()' method on the loaded assmebly, but that doesn't seem to give any indication where the assemblies should be loaded from... Do I need to search for them myself? If so, what's the best way to do this?
It seems like other people might have come across this before, and I don't want to re-invent the wheel.
-
Update:
The EXE is checked in because thats how we distribute our in-house tools to the teams that use them. Its not optimal for this use-case, but I don't have the opportunity to change that policy.
Disclaimer: I don't use Windows, though I am familiar with its strange way of locking things.
In order to update your application while it is running, you'll likely need to have two processes: The executable itself, and an update “helper” application that will finish the update process. Let's say that your application is ProcessA.exe and your update helper is Updater.exe. Your main program will download a new copy of the executable, saving it with a random name. Then you run your updater program, which watches for the termination of your current process. When your process terminates, it displays a quick window showing the status of the update, moving the new executable into the place of the old one, and then restarting that program.
It'd be more elegant to be able to emulate POSIX filesystem semantics and be able to delete the currently-running process disk image and replace it with a new file, but I don't know if that is even possible on Windows. On a POSIX system, you can delete an in-use file and it won't actually be deleted until any remaining file handles are closed, though you can then reuse the filename.
You might want to check out an article written at CodeProject that talks about this. It also has a follow-up article.
Good luck!
Does the program need to keep running while updating?
Typically to update a program which is running you would copy over any of the files that are to be replaced to a temporary folder. Then shut down the old instance, delete it and move the new files over to the correct locations then re-launch it.
This allows for minimal down time of the application since the longest part is usually the copy and the file move is very fast if the temporary folder is on the same logical drive.
Although Michael's answer is one way of doing this, there are tools out there that are explicitly for managing what's installed on the desktop.
What you are doing with the exe being checked into source control is not normal. If you have a windows domain controller, you can use Group Policy to push programs down to the client. Alternatively, you could use something like Altiris to handle it.
If you must continue the way you are going then you have two options. One, using a helper / loader app which does a version check on launch. This is similar to how firefox works.
The second way is to build a helper service that sits in memory and polls every so often for updates. This is how Google Chrome, Adobe, etc work.