Use Dll of the same name for different projects - vb.net

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.

Related

Reference SSRS assemblies w/o referencing specific SSRS server

I am trying to create a library that holds some utilities that facilitate SSRS reporting inside either winform or .net framework websites.
I have used the code on 2 projects, now looking to use it on a third. that's about the time i usually stop and break the code out into something reusable.
My issue is that I need to make a couple references to SSRS classes
Public Warnings() As SSRS_E.Warning = Nothing
Public credentials() As SSRS_.DataSourceCredentials = Nothing
The SSRS_E reference resolves to SSRS_ReportExecution2005
and the SSRS_ reference resolves to SSRS_reportservice2010
These are valid in my old projects because I have service references to a specific SSRS service.
Is it possible to locate these assemblies outside of a specific installation?
I do not want to get into a situation where I have to 'fix' the reference everytime I open the utility dll in a different project...

Check and Notify non-existence of Microsoft.VisualBasic.PowerPacks

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.

How can I specify an endpoint class with NServiceBus.Host.exe?

I have have a solution that I created with the new modeler tools. This gave me
two full "endpoints" in a single solution.
Now when I run them through my automated build, I have two dlls in the same
folder that implement IConfigureThisEndpoint.
If I just run NServiceBus.Host.exe \install (to get a Windows Service), it gives
me the (expected) error that there is more than one class that can be used.
I did some searching and Udi states here:
http://tech.groups.yahoo.com/group/nservicebus/message/3937 that "You can
specify which class you want loaded and avoid these issues - as the server
project in the pub/sub sample shows".
I looked at the pub/sub sample and I can't see how I can specify my class (at
least not at the command line).
Is there a way to get around having to modify my build to put the files in
separate folders? (Not really an easy task for me.)
Add a config entry to your app settings with the key EndpointConfigurationType and the value being the assembly qualified name of the type.

Is there a way to change referenced library files during processing?

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.

How to retrieve a list of tableadapters?

BACKGROUND:
Most of my programs use table adapters, and the connection strings are stored in app settings. This works fine, but was a real PITA when switching from development to production environment. I had to change manually the connection strings before and after starting my work on any app.
After a bit of research I found how to switch connection strings for table adapters dynamically. By simply adding a custom property for connectionString, I was able to acheive this. But I still have to add code in the new event for each application so the connection strings get switched when it loads. (My connection strings are kept as an app property setting in a common DLL. I just keep one copy of the DLL with my connection strings locally, and one copy o the DLL with the production connection strings on the production server.)
NEW PROBLEM
I'd like to take this one step further and have either have the datasets change the connection strings for all table adapters they each contain when they load using the new event, or do the same from a VB module. I may have up to 3 datasets at any one time.
I do depend a lot on intellisense to help me determine which methods and properties are available, but I can not find a way to retrieve a list of the table adapters in my datasets. It does not appear that they are a part of any collection of objects as far as I can tell. I've searched a quite bit for a solution, but no luck.
Marshall
You might want to reconfigure the location of the connection strings. Make your presentation layer (i.e. the application) contain the connection string in it's app.config. Now here's the cool part ... any .DLL that is being used by the application can access the application's app.config using the ConfigurationManager.ConnectionStrings("MyConnectionString").ToString function. Your .DLL would call the connection string by name, and the call propagates up to the application's app.config. If you don't want to hard code "MyConnectionString", then you should simply pass the connection string to the .DLL via a property of an object.
If you DON'T want to rearrange the connection string "ownership", simply expose the .DLL's connection string from it's own config file via a static object in the .DLL which the application can read. Assign that to the TableAdapters.
As a side note, if you are already familiar and comfortable with what appears to be your custom DLL's, move all of the data access logic into its own DLL as a Data Access Layer (DAL) - get the data access logic out of the presentation layer!