I have a coded ui test that I want to start by using batch, its a .dll file.
The reason I'm calling it from a batch file is that the server has to be restarted before this test can be carried out.
Is it just a simple call test.dll or do I have to do other stuff?
Update Code Found
Playback.Initialize();
TestProject.CodedUITest1 coded = new TestProject.CodedUITest1();
coded.CodedUITestMethod1();
Playback.Cleanup();
Take from Here, Its missing two reference addings from the private assemblies:
Microsoft.VisualStudio.TestTools.UITest.Extension.Uia.dll
Microsoft.VisualStudio.TestTools.UITest.Extension.IE.dll
Hope this helps other people looking to do this
You can't run a Dll file like you can an exe. A Dll contains code intended to be used by a program, it means one source of code can be used by many programs, which saves duplicating the code.
Usually the Dll will have documented functions you can call via a program, unless you built it yourself in which case you would know :)
Try and find the program that uses the Dll and call that, or find the docs for it and run the function from rundll32 as #PA. suggested.
DLLs are dynamic libraries that need to be linked and called from an application program. Every DLL has its own exported interface, or collection of entry points to be called from the external executable, or, may be, from another DLL.
Windows provides a set of calls to help caller programs to load, detect entry points, and unload DLLs. Beyond this limited common functionality, there are endless combinations of ways of using a DLL, in the calling conventions, in the ways of passing parameters, in the types of the parameters, in the ways of returning data, in the ways of synchronizing, notifying events, interrupting, multithreading, in almost every aspect of programming models.
Having said so, it is possible that your DLL is expected to be called from some specific application program, and thus is possibly following and strict and well defined API. One such type of DLLs are Windows System DLLs that are intended to be run with rundll executable program. rundll32.exe is the Windows system executable that launches and invokes functions that are packed and shipped in .dll files, from a DLL that is explicitely programmed to be called this way.
to invoke your TestFunction inside your TEST.DLL, passing 1234 as a parameter, you'd use
RUNDLL32 TEST.DLL, TestFunction 1234
Rundll will perform for you the following tasks
Load TEST.DLL via LoadLibrary().
Address the TestFunction function via GetProcAddress().
Call TestFunction function, passing the rest of the command line
Unload the DLL and exit.
Related
In compiled system languages (like C/C++), generally, the entry point is resolved at link time, which gives the ability to have the main function in a DLL so the linker won't complain and set the entry point address to the symbol in the DLL (or the function in the import library, not sure about that).
I recently started using C# and I would like to do something similar, where I have the Main method in a library (which preferably build against .NET Standard) and the actual exe don't define any entry point and uses the one in the library.
I get that I could just write a Main method in the exe and call the Main of the library in it, but the point is that I would like to avoid that.
I believe Winforms and WPF provide something similar, so hopefully what I'm trying to do is possible, otherwise, please educate me on the reasons why .NET doesn't provide such mechanism.
There seems to be a misunderstanding here:
In .NET, the only difference between a DLL and an EXE is purely the presence of .entrypoint in the header, which identifies the starting method that the CLR bootstrapper calls.
If there isn't one then it's a library rather than an application. It makes no sense to have an EXE which has no .entrypoint on any method, it won't run because the CLR bootstrapper won't know what to do with it.
Winforms and WPF do not do what you claim: they have a normal .entrypoint, it just happens to be boiler plate code which you don't need to worry about.
For clarity: the actual extension of the file is somewhat irrelevant. It's perfectly legal to call an assembly whatever you want, and you can link an assembly containing .entrypoint within another one, whether or not it has .exe extension or any other.
However, Windows will only bootstrap a file automatically if it has the .exe extension, as the CLR bootstrapper itself needs bootstrapping. You can though call AppDomain.ExecuteAssembly which essentially does the same thing from within another app.
So basically I am creating my own dll for use in a c# codebase, using c++ and a c-style layer for exporting functions. The issue is that both the c# part of the code (which actually runs and uses the dll) and my library itself both use another library (it's imgui, so lets call it such, even though it is irrelevant mostly) that runs on global state.
I initialize imgui to certain settings in my own dll and then use some of its functions in the c# code. Currently I am simply compiling the library into my dll and doing a c# binding myself that issues calls to imgui through my own dll. My question is whether I can use imgui as a dll for use both in my own dll and the main c# program in such a way that state is shared and the initialization step initializes the same code for both my own dll and the c# code.
That is, the c# code calls one of my functions in my own dll to initialize it, that function imports a dll (imgui), in the common directory for both my dll and the executable, and initializes IT. After this, the main c# program that imports both my dll and imgui then calls imgui functions to manipulate it's state. Will my dll and the main c# program be manipulating the same imgui state?
Generally yes
I say 'generally' because there are some conditions:
Everything needs to be in the same process (you are not clear on this but I assume so)
Both callers need to be able to get some handle on the state. So for example, if the state is memory allocated on the heap, then both callers need to be able to get a pointer to it, or else it needs to be a global variable somewhere they can access, either directly or indirectly.
Really it is the same as if it was 3 different C# modules
(also adding the disclaimer to think if you really need to use the C++, but I'm sure you have your reasons)
I am not sure the best way to explain this so please leave comments if you do not understand.
Basically, I have a few libraries for various tasks to work with different programs - notification is just one example.
Now, I am building a new program, and I want it to be as lightweight as possible. Whilst I would like to include my notification engine, I do not think many people would actually use its functionality, so, I would rather not include it by default - just as an optional download.
How would I program this?
With unmanaged Dlls and P/Invoke, I can basically wrap the whole lot in a try/catch loop, but I am not sure about the managed version.
So far, the best way I can think of is to check if the DLL file exists upon startup then set a field bool or similar, and every time I would like a notification to be fired, I could do an if/check the bool and fire...
I have seen from the debug window that DLL files are only loaded as they are needed. The program would obviously compile as all components will be visible to the project, but would it run on the end users machine without the DLL?
More importantly, is there a better way of doing this?
I would ideally like to have nothing about notifications in my application and somehow have it so that if the DLL file is downloaded, it adds this functionality externally. It really is not the end of the world to have a few extra bytes calling notification("blabla"); (or similar), but I am thinking a lot further down the line when I have much bigger intentions and just want to know best practices for this sort of thing.
I do not think many people would
actually use its functionality, so, I
would rather not include it by default
- just as an optional download.
Such things are typically described as plugins (or add-ons, or extensions).
Since .NET 4, the standard way to do that is with the Managed Exensibility Framework. It is included in the framework as the System.ComponentModel.Composition assembly and namespace. To get started, it is best to read the MSDN article and the MEF programming guide.
You can use System.Reflection.Assembly and its LoadFile method to dynamically load a DLL. You can then use the methods in Assembly to get Classes, types etc. embedded in the DLL and call them.
If you just check if the .dll exists or load every .dll in a plugin directory you can get what you want.
To your question if the program will run on the user's machine without the dlls already being present - yes , the program would run. As long as you dont do something that needs the runtime to load the classes defined in the dll , it does not matter if the dll is missing from the machine. To the aspect you are looking for regarding loading the dll on demand , I think you are well of using some sort of a configuration and Reflection ( either directly or by some IoC strategy. )
Try to load the plugin at startup.
Instead of checking a boolean all over the place, you can create a delegate field for the notification and initialize it to a no-op function. If loading the plugin succeeds, assign the delegate to the plugin implementation. Then everywhere the event occurs can just call the delegate, without worrying about the fact that the plugin might or might not be available.
I need to create a desktop app in C# that will require a specific set of parameters when loaded, either by command line (or a direct reference?) from an old VB6 application or as a reference from a vb.net application.
I need parameters such as name, city, state, zip and a few others. I'm not sure yet what all I'll need yet. I know I'll need some very basic account information to be passed in.
What would be the best way to accept these parameters where they can be called from either application?
I started to create a class that contained the needed parameters, but I am not sure if a VB6 application can reference the exe as a dll and pass a it the class back. I've not called a .net application from vb6 so I don't know the requirements and I don't have vb6 installed.
Any suggestions?
Write a DLL/library. Then write an EXE that takes the parameters and just references that DLL the same as other code would.
This may help, Command Line Parameters Tutorial
http://msdn.microsoft.com/en-us/library/aa288457(v=vs.71).aspx
I want to "hot" load some pre-packaged assembli(es) into a separate AppDomain, the thing however is I do not know the name of the entry point class or even the assembly file. I need to find this entry point so I can run some initialization routine.
So what I intend to do is to run ReflectionOnlyLoad on all the files and find the one that follows a certain convention ie. annotated/implements a certain interface etc.
Question is, will I start leaking memory if I were to run ReflectionOnlyLoad from the main AppDomain over and over? If this can't be run from the main app domain, what are my options, because again I do not know where the entry point is.
Also any additional information about the subtleties in using ReflectionOnlyLoad is appreciated.
I recommend Mono.Cecil. It's a simple assembly you can use on .net (it doesn't require the Mono runtime). It offers an API to load assemblies as data, and works pretty well. I found the API easy to work with, and it suffered from none of the problems I experienced when using reflection-only-load.
You can also use CCI, which is an open source project by MS that offers an assembly reader.
See also: CCI vs. Mono.Cecil -- advantages and disadvantages
ReflectionOnlyLoad won't solve your problem, see docs
Why don't you execute the code for finding the entry point etc. in the new AppDomain?
Cannot reflect through the dlls. Even with reflection only load, the type sticks to the main AppDomain.
2 Solutions:
Put the entry point in an xml somewhere and parse that.
Use a
2 stage AppDomain, one for the reflector, and then another for the
actual object.
I picked (1) since it's the most sensible.
(2) I have to pass through 2 separate proxies in order to issue command to the actual remote object, that or I need to couple the interfaces much more closely than I like. Not to mention being a pain to code.