I have a .NET customer framework that functions much like a Workflow. It uses reflection to get a listing of all of the processes it is capable of from a specific folder, and starts them via reflection with a known start point (all of them have a method called "Process"). Since these files are only called to do the processing and not part of the compile... is there a way for me to be able to drop in a new reference library (DLL) for one of the processes that is being updated without restarting the whole process?
Here is my flow...
START
Load list of references
Load work, assign to references
After X Time, refresh references (or
on WCF refresh command being sent)
Is it possible to do this, or do I do I need to actually stop and restart the assembly base to be able to recognized the new reference file?
Yes you can with Assembly.Load but I think you need to look at MEF first.
Related
In a simple windows form application on VS 2010 I have put a ovalShape using power packs.
The simple Form
Now automatically this action puts the reference of Microsoft.VisualBasic.PowerPacks.Vs in to project properties.
when deploying this in different PC obviously the (a)powerpacks needed to be installed if this application doesn't work, (b) or it can set to "copy local = true" in reference properties so that it should sit to next with the application.
assuming (b) is not an option, since it is a solitary executable, (a) is the only option. in this way if the target machine does not have powerpacks the requirement is to notify it to the user in the first place.
apparently the dll will be deployed in when using the "VisualBasicPowerPacksSetup"
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic.PowerPacks.Vs\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.PowerPacks.Vs.dll
so the blind approach is just to check if the above file not exist then prompt user to install "VisualBasicPowerPacksSetup". but i feel its more accurate if the application able to actually check in registry level.
in registry "Microsoft.VisualBasic.PowerPacks" records in several location, thus makes a confusion.
how to identify the correct key and what should be correct way of checking this reference in vb ?
You could just try to create an object defined in the dependency and catch the resulting exception.
Handling this you could ask the user to install the package. This is probably not considered good practice but should get the job done.
I have a simple BizTalk map that uses a scripting functoid to call an external assembly function. This function, however, relies on a value from configuration. For a live server, this config file is BTSNTSvc.exe.config, but what file is used when testing a map in Visual Studio?
I have attempted to place Debug.WriteLine calls in my external assembly to trace out the location of the configuration file, but nothing appears in my trace listener, either.
I need to maintain the ability to switch values in config, but I'd also like to retain the short turnaround time afforded by testing in VS, rather than having to fully deploy every time. Is this possible?
I suppose that would be the devenv.exe.config.
C:\Program Files(x86)\VSVersion\Common7\IDE\devenv.exe.config
Another way would be to make a unit test for the map instead of using the "Test Map"-functionality.
I am trying to develop a small utility program that will be deployed with other application that we already have. In order to make the utility work, I need to know the connectionString used by the application to access the database.
Since I have old and new applications, they have different ways to connect to the database. So I figured the way I would do it is something like that
All project will need to implement a dll named "Connect.dll"
This dll will include one public function name GetConnString. This function will return a string which correspond to the connection string to use to connect to the main database.
What I wanted to do was to simply include the utility in the same folder as the application and use the Connect.dll found within the folder. So far though, unless I copy the original dll found within my utility project, the utility will crash. Is there any way to do this ?
Regards,
Create a non signed assembly and enforce that all the clients use the same assembly version with (of course) the same signature.
In your utility set the property "Specific Version" to False.
This should do the trick.
I want to create a file on Mac OS X (10.6) that will be deleted automatically when my process goes away. Is this possible? It would be very handy for a file locking scheme I am implementing. Preferably as a Cocoa or Carbon call.
I know that on Windows, this is possible. It's a very neat feature, but I don't know if it is something that needs to be supported by the file system.
On win32 you can call CreateFile with FILE_FLAG_DELETE_ON_CLOSE.
In .net you can create a FileStream with FileOptions.DeleteOnClose as argument.
If you are writing your own program, you could use tmpfile() call.
It creates a temporary file that get removed automatically on program termination.
You could have your app delegate to create and delete the file via the NSApplicationDelegate, however, the file would remain there if the user force quits/shut down. If force quitting is not part of your concern, then this should work. If not, you can create a simple launch agent that checks if your process exists, and if not, delete the file.
You can register an atexit() handler to delete the file, but this will not necessarily be completely reliable, particularly if the program crashes.
If you want proper file locking, consider using flock(), although, it is cooperative.
I'm creating a self updating app where I have the majority of the code in a seperate DLL. It's command line and will eventually be run on Mono. I'm just trying to get this code to work in C# on windows at the command line.
How can I create a c# application that I can delete a supporting dll while its running?
AppDomain domain = AppDomain.CreateDomain("MyDomain");
ObjectHandle instance = domain.CreateInstance( "VersionUpdater.Core", "VersionUpdater.Core.VersionInfo");
object unwrap = instance.Unwrap();
Console.WriteLine(((ICommand)unwrap).Run());
AppDomain.Unload(domain);
Console.ReadLine();
at the ReadLine the VersionUpdater.Core.dll is still locked from deletion
The ICommand interface is in VersionUpdater.Common.dll which is referenced by both the Commandline app and VersionUpdater.Core.dll
The only way I've ever managed something similar is to have the DLL in a separate AppDomain to the assembly that is trying to delete it. I unload the other AppDomain and then delete the DLL from disk.
If you're looking for a way to perform the update, off the top of my head I would go for a stub exe that spawns the real AppDomain. Then, when that stub exe detects an update is to be applied, it quits the other AppDomain and then does the update magic.
EDIT: The updater cannot share DLLs with the thing it is updating, otherwise it will lock those DLLs and therefore prevent them from being deleted. I suspect this is why you still get an exception. The updater has to be standalone and not reliant on anything that the other AppDomain uses, and vice versa.
Unwrap will load the assembly of the object's type into the appdomain that calls it. One way around this is to create a type in your "base" assembly that calls command.run, then load that into your new appdomain. This way you never have to call unwrap on an object from a type in a different assembly, and you can delete the assembly on disk.
When I built a self-updating app, I used the stub idea, but the stub was the app itself.
The app would start, look for updates. If it found an update, it would download a copy of the new app to temp storage, and then start it up (System.Diagnostics.Process.Start()) using a command-line option that said "you are being updated". Then the original exe exits.
The spawned exe starts up, sees that it is an update, and copies itself to the original app directory. It then starts the app from that new location. Then the spawned exe ends.
The newly started exe from the original app install location starts up - sees the temp file and deletes it. Then resumes normal execution.
You can always use MOVEFILE_DELAY_UNTIL_REBOOT to delete on reboot. This is most likely the least hackey way todo this sort of thing, by hackey I ususally see things like; loading up new DLL's or injecting to explorer.exe even patching a system dll to get loaded into another process, etc...
MoveFileEx From MSDN;
lpNewFileName [in, optional] The new
name of the file or directory on the
local computer.
When moving a file, the destination
can be on a different file system or
volume. If the destination is on
another drive, you must set the
MOVEFILE_COPY_ALLOWED flag in dwFlags.
When moving a directory, the
destination must be on the same drive.
If dwFlags specifies
MOVEFILE_DELAY_UNTIL_REBOOT and
lpNewFileName is NULL, MoveFileEx
registers the lpExistingFileName file
to be deleted when the system
restarts. If lpExistingFileName refers
to a directory, the system removes the
directory at restart only if the
directory is empty.