I have an .exe file and it is working properly. It connects to a SQL Server 2012 database. I need to know the authentication to the database. Is there any way to do this? Can I get the connection string from .exe file some way?
If your .net application is not obfuscated (protected against decompilation) you can get it's c# source by decompiling it with a tool like Resharper from JetBrains (contains assembly explorer tool) or free tool called ILSpy http://ilspy.net/.
I'd just add up that if it is not a tool written by you or your company, decompiling it might be a violation of a license agreement of this application.
If it is a fully standalone .exe, there are a couple of options:
Various configuration files that include the connection details may be compressed / merged into the executable, and can be extracted by various means.
The connection details are hard coded into the C# code, which can then be decompiled.
For decompilation, try dotPeek or ILSpy. For simple extraction, you can try 7zip.
As suggested you can try to decompile your executable (assembly) using Telerik JustDecompile (it is free).
Just drag and drop your file into the application, it might ask you for some dependencies. Skip them if they do not seem related to your application and you will be able to see the decompiled code.
Related
We are developing a small framework within the company and there is a small weird issue with pdb files.
While developing framework, we also commit pdb&dll outputs and related projects are referenced directly to these dlls.
But when i build and commit these dlls, my companions cannot navigate to sources of framework. When someone else builds, i cannot navigate to source.
Only thing i can do is to use resharper's navigation via "navigate to -> decompiled sources".
There is something wrong i think. They are the same files so that i should be able to navigate to their files directly.
Btw, we do not version framework. All dlls use same 1.0 version.
Anyone having an idea?
I found the answer. Using DUMPBIN I examined all pdb files and there were full paths of last build, which is different in my computer.
For ex: my collegue build framework project in d:\projects path however, working directory in my computer was c:\projects so that pdb files somehow not found (which is veird. The paths should be relative imo)
When one of us changed framework project path and if we both use the same path; no matter who built that project last, it just worked. I can navigate source codes directly in Visual Studio.
It can be that you need to disable Optimize Code on release build to make it work. Try that..
Im searching for a way to make my c#.net Application portable (or at least no installation needed). Some Background: I'm developing a small File-Manager for our Customers. As not every Employee of our Customer got Admin rights I need to hold it as easy as possible to use it.
My idea was to just deliver an .exe or Zip(containing .exe + dll of .net), that all Employees can use it by double clicking.
Is there any way to "bind" the dll to the exe?
Why not just use ClickOnce deployment?
http://msdn.microsoft.com/en-GB/library/142dbbz4%28v=vs.90%29.aspx
No admin rights required... auto updating... what's not to like?
(Just deploying executables is a great way to eliminate your ability to update your clients... why do that?)
You can combine multiple .NET assemblies together using ILMerge: http://research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
It's somewhat equivalent in concept to a static linker from C/C++ (except pretend that .lib files are directly executable).
Try ILMerge,
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly
http://www.microsoft.com/en-in/download/details.aspx?id=17630
I also use this command line tool to merge several dlls and exe into single exe, use is very simple:
ilmerge /target:winexe /out:destination.exe source.exe dll_1.dll dll_2.dll dll_3.dll
In basic the program written in .net is 'portable' - you do not need to install it. (but the compatible .NET framework must be installed on client machine)
If you like to provide single assembly, you need to download and install the IlMerge utitlity (see Dai's answer) and then have either post-build command defined or I usually do a bat file with content like this:
"c:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe" /target:winexe /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0" /out:ALLINONE.exe PROGRAM.exe LIBRARY1.dll LIBRARY2.dll
Note, the paths depends on how it is on your system...
Also I recommend to 'obfuscate' your assembly - you can use for example good opensource utility 'ConfuserEx'
I made a WPF program which uses SQLite. And by using Visual Studio 2012, it generates both Debug and Release version exe file. When I go to Debug or Release directory and run my exe file, e.g. MultiStart.exe, it can run normally.
But if I copy the MultiStart.exe to my Desktop and try to run it, it failed.
By several tests, I found that I also need to copy files MultiStart.exe.config and System.Data.SQLite.dll to my Desktop. And then it can run now.
But why? Do we have better solution so that I can make it run without addition files?
Thanks!
Why my WPF program cannot run without Visual Studio?
The question title is not really accurate since it's not really related Visual Studio. MultiStart.exe is dependent on configuration (MultiStart.exe.config) as well as other assemblies (System.Data.SQLite.dll). Without these dependencies the application cannot run (because that is how .NET works).
WPF doesn't necessarily need a config file to run so the question is what is in your config file that the application needs. It might be possible to move this configuration information into the code (e.g. connection string) and remove the app.config but then the values will be hard coded in the application.
In terms of dependent assemblies, instead of deploying them it is possible to embed them as resources and then use the AppDomain.AssemblyResolve Event to read the assembly from a resource (see Embedding assemblies inside another assembly for an example).
Another approach instead of embedding assemblies as resources is to merge them into one assembly. ILMerge is a popular choice for merging assemblies but I read that it can have issues with WPF assemblies (not sure if that applies to you). See Merging dlls into a single .exe with wpf for some other ideas for merging assemblies with WPF.
Note that setting PATH variables does not work because .NET does not use the PATH for resolving assemblies -- see How the Runtime Locates Assemblies for the details.
Another, option instead of copying the MultiStart.exe to the desktop is to use a shortcut on the desktop that links to the appropriate directory. Perhaps that is a simpler solution
You can also use ILMerge to merge all dependencies into single .exe file to simplify distributiuon of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
Example of usage: ilmerge /target:winexe /out:YourDestinationApp.exe
YourCurrentProgram.exe System.Data.SQLite.dll
Better solution that i used to do with my windows form apps is, Copy the entire folder, which contains supporting files. place it where you want. then create a shortcut of your .exe on your desktop. That always worked for me.
Because you are missing some dependency. You can open your config file and set the dependency...but I wouldn't recommend you to change config file manually.
You can also copy the dependent dll in system32 folder. ..but its only a trick because exe first search dlls in current folder than system 32 folder.
Because you're missing things from your PATH. Visual Studio is probably set to copy DLLs to the target directory on build.
You're almost certainly pulling in external libraries. Some of these are part of .NET, while others are packaged in libraries in specific folders. When you start your exe, it looks in your PATH and the current folder for everything (which includes all DLLs Visual Studio copied).
When you moved the exe to the desktop, suddenly it had no idea where those DLLs are. You haven't specifically added them to your PATH, and they are no longer in the current folder. This is why copying those DLLs to your desktop magically made them work.
Unless you stop use SQLite, there is not a way for you to not need that DLL (there are lots of ways to package/reference it though).
I'm trying to understand how a Silverlight app communicates with its server. Communication is encrypted. I would like to see how messages look like before encryption. I came up with this idea: when browser requests the .xap file, I serve a version containing a patched DLL that does not encrypt anything. I created this DLL by patching C# code with reflexil.
What tool should I use to deliver this patched .xap file? Fiddler? Only one file needs to be replaced, all other requests from the browser should go to the original server.
Is there a simpler way of doing this? For example, does anyone know, where exactly DLL files from .xap files are extracted? How are they loaded? Perhaps it's easier to find where they get extracted and patch the already unpacked version? I used process monitor, but IE seems to be unpacking XAPs in memory.
EDIT:
I did not create the application, that's the problem. I want trick IE into loading a patched version of a DLL from the original XAP.
Don't exactly understand what you are trying to achieve, but with regards to your last question on unpacking XAPs, you can access the downloaded xap files in the following location
C:\Documents and Settings[UserName]\Local Settings\Temporary Internet Files\
rename the package to .zip instead of .xap, unzip, and access your dll there?
I made an application for an automated invoice management system for my company. I am using the tessnet2 library for OCR. The whole application works properly on my development machine but as soon as I put the code on the target machine, wihout the development framework, it gives an error of references not found in the .DoOCR method.
I read that you had the same problem and I hope you can help me with it.
I have put the language files in the same directory as the application itself, but its not helping me.
Any help or suggestions will be highly appreciated.
Thanks
Regards
Vin
Look in the VS folder (under Program Files - you'll need to look in sub-folders) for a program called "Depends". This looks for dependencies from EXE and DLL files. Run it with the DLL as a command-line parameter, and that should list what files are needed by that DLL. Then see if they are all present on the destination system.