I want to read dll contents from command line api So I can access it at run time.
Is there any tool that has a CLI API for de-compiling code?
Dependency Walker has a console mode. It of course doesn't decompile, but that is most likely not what you need anyway. (That's not needed to access a DLL)
Related
I have a file-translation library in the form of a Win32 EXE and a stub DLL that feeds parameters to it. I have written a lightweight (~500 lines) VB.net app that creates the file to be translated, then calls the DLL to launch the EXE. Unfortunately, this results in my EXE, their EXE, the DLL and another supporting file. I'd prefer to have a single file.
Following the basic idea here doesn't seem to help - I need to have all three files able to see each other, and it's not clear how to do this from those examples. I've also seen this, but again, this appears to be running an EXE that is "beside" the .net code, not embedded within it.
So, is there a way to run the EXE/DLL/supporting file "in situ"? Are the Assemblies ultimately a directory structure where I can run the EXE? And if so, how does one find/refer to these files?
I'm developing a Visual Basic application using Visual Studio. My application worked fine with command line arguments until I compiled a "Publish" the first time. Now if I try to run the executable file generated in the debug folder I get a System.IndexOutOfRangeException thrown. If I try to run it inside Visual Studio I get this warning:
The current project settings specify that the project will be debugged with specific security permissions. In this mode, command line arguments will not be passed to the executable. Do you want to continue debugging anyway?
And then the code run without errors, but it does not create a new .exe file in the debug folder.
What have happened? How can I fix this problem? My code worked just fine until I tried to "publish" it. I haven't changed a single line.
The "Publish" feature in Visual Studio uses ClickOnce deployment technology. There's a pretty good overview of ClickOnce, and how it differs from MSI deployment, at https://msdn.microsoft.com/en-us/library/142dbbz4(v=vs.90).aspx.
The MSDN topic "How to: Retrieve Query String Information in a ClickOnce Application" at https://msdn.microsoft.com/en-us/library/ms172242(v=vs.90).aspx confirms that "It is not possible to pass command-line arguments to a ClickOnce application. If you want to supply arguments to the application, you must deploy it over the Web and supply query string parameters in the URL."
You can create still create File Associations for a ClickOnce application, but it requires specific configuration steps as well as modified code. The following blog posting walks you through this:
http://blogs.msdn.com/b/mwade/archive/2008/01/30/how-to-add-file-associations-to-a-clickonce-application.aspx
Overall, unless you have a specific need to use ClickOnce, I would suggest sticking with XCopy or MSI deployment.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.
We have a Powerbuilder 10 application that is using .Net COM assemblies. We are trying to embed the manifest in the PB application (to invoke COM assemblies without registration). The merged manifest file has added sections for dependecies on the .Net COM assemblies. We have tries various tools to inject the new manifest with different results
- using GenMan32 to inject truncates the application from 6MB to 45KB.
- using ResourceTuner, the file size looks okay, but trying to launch application gives "Fatal Disk Error".
Any suggestions on invoked .Net ComEnabled assembly from PB without registration?
Have you tried it with an external manifest and ensured that works? If an external manifest doesn't work, then the manifest information isn't correct.
Once you have a valid external manifest, you might try the Manifest Tool (MT.EXE) from the .Net SDK. It works well with true EXE files. As Terry noted though, the PB generated executable contains additional information that tools that manipulate the EXE need to respect or they will break it.
http://blogs.msdn.com/patricka/archive/2009/12/09/answers-to-several-application-manifest-mysteries-and-questions.aspx
This is more a redirection than an answer. One thing you need to be aware of is that PowerBuilder produces executables that do not follow standards for Windows executable files. Essentially they are a bootstrap routine to load the PowerBuilder virtual machine, plus a collection of class definitions (objects). The cases you've brought up are not the first I've heard of where utilities meant to modify executables don't work on PowerBuilder executables.
As for a positive contribution on what other directions to follow, I don't really know enough to give qualified advice. If it were me, I'd try to register the COM object if ConnectToNewObject() fails, but I've got no idea if that possible or if that route is a dead end.
Good luck,
Terry.