Hi!
What do you think about proposition to add in connection string a new
parameter called "ClientLibrary" which will be used with "ServerType" = 1.
Rules may be next:
1) If "ServerType" = 0 then "ClientLibrary" ignored
2) If "ServerType" = 1 and "ClientLibrary" not specified then behavior
is s
sasha wrote:
> 3) If "ServerType" = 1 and "ClientLibrary" specified then provider works
> with specified client library.
Do you think with specified path to DLL?
--
Jiri {x2} Cincura
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
-
> Do you think with specified path to DLL?
I think path should be optional.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT &
if I'm wrong!
Regards,
Paul
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of sasha
> Sent: Tuesday, February 27, 2007 6:53 PM
> To: firebird-net-provider@lists.sourceforge.net
> Subject: [Firebird-net-provider] Connectio
sasha wrote:
>> Do you think with specified path to DLL?
>
> I think path should be optional.
Yes, but this will not work with DllImport. It accepts only constant
string as param. And using LoadLibrary will work only on Windows, so for
Linux/Mono it will be out.
BTW if the DLL is in standard d
Jiri Cincura wrote:
> string as param. And using LoadLibrary will work only on Windows, so for
> Linux/Mono it will be out.
And LoadLibrary has another problem. You will need to load all icxxx.dll
manually too...
--
Jiri {x2} Cincura
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
Mercea Paul wrote:
> Correct me if I'm wrong!
You're right. And (I'm not sure now how is this handled in unmanaged
world) you can paths where to try to load libraries (100% sure for
managed) into config.
--
Jiri {x2} Cincura
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
--
> Yes, but this will not work with DllImport. It accepts only constant
> string as param. And using LoadLibrary will work only on Windows, so for
> Linux/Mono it will be out.
You can make it work using Reflection.Emit and dynamically generating the
FirebirdSql.Data.Client.Embedded.FbClient class a
> This would probably be easier than using LoadLibrary directly (and
> especially GetProcAddress - in fact, is GetProcAddress even callable from
> C#?) PLUS it would be just as cross-platform as before!
Oh, I just answered my own question: you can call GetProcAddress in C#,
using the new (in .NET
Dean Harding wrote:
> You can make it work using Reflection.Emit and dynamically generating the
> FirebirdSql.Data.Client.Embedded.FbClient class at runtime, with the full
> path to the fbembed.dll file in the [DllImport] attributes.
I have 2 questions. Why to change somethig what's working and wo
Sent: Wednesday, 28 February 2007 9:40 am
> To: For users and developers of the Firebird .NET providers
> Subject: Re: [Firebird-net-provider] Connection string enhancing
>
> Dean Harding wrote:
> > You can make it work using Reflection.Emit and dynamically generating
> the
> &
Dean Harding wrote:
> I'm not saying it HAS to be changed, but it WOULD be a neat feature. If the
> argument is that we shouldn't add new features just because it would involve
> changing things, then why do anything?
Yeah, but from my POV this is low priority.
> Reflection.Emit refers to the nam
day, 28 February 2007 9:59 am
> To: For users and developers of the Firebird .NET providers
> Subject: Re: [Firebird-net-provider] Connection string enhancing
>
> Dean Harding wrote:
> > I'm not saying it HAS to be changed, but it WOULD be a neat feature. If
> the
> &
> Yes, but this will not work with DllImport. It accepts only constant
> string as param. And using LoadLibrary will work only on Windows, so for
> Linux/Mono it will be out.
>
> BTW if the DLL is in standard dirs there's no problem with loading,
> isn't it?
The problems are in FirebirdSql.Da
> What do you think? I can try to implement this.
> Which way is better, Dean's or myne?
Well, I'm going to give my method a go myself (I got myself interested
enough to try ;) so I'll let you know the outcome :-)
Dean.
-
I had a go, and it wasn't all that difficult. I've uploaded the files that I
changed from FirebirdClient-2.1.0.0 Beta1 (which was the version I had)
here:
http://codeka.com/tmp/fb-beta1-updated-files.zip
The main interesting thing is IFbClient.cs and FbClientFactory.cs. IFbClient
is a new interfa
sasha wrote:
> I do not want to recompile provider for using it with fbclient.dll
> instead of fbembed.dll.
Seems I have lost myself. All these changes care about fbclient vs.
fbemded DLL name?
I think it was about full path to DLL and not full path.
--
Jiri {x2} Cincura
http://blog.vyvojar.c
Looked in your codes - looks cool :-)
Yet one way to make that wee need is to _compile_ concrete classes from
their sources using
System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(...)
Steps are next:
1) Make interface IFbClient
2) Make concreate class template, for example:
> Seems I have lost myself. All these changes care about fbclient vs.
> fbemded DLL name?
In my case yes, but i think other people may want to specify full path
to client dll. What should i do if my application should work with both
embedded and normal server or on mono in windows and linux or
Hello:
> I'm not saying it HAS to be changed, but it WOULD be a neat feature. If the
> argument is that we shouldn't add new features just because it would involve
> changing things, then why do anything?
That isn't the quest the quest is if there are a way to do it in a
cross-platform way using
Dean Harding wrote:
> http://codeka.com/tmp/fb-beta1-updated-files.zip
Hi,
I've tested this and works!
--
Jiri {x2} Cincura
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
-
Take Surveys. Earn Cash. Influence the
sasha wrote:
> In my case yes, but i think other people may want to specify full path
> to client dll. What should i do if my application should work with both
> embedded and normal server or on mono in windows and linux or i have a
> few instances of diffirent fb server?
Well, still don't see
> That isn't the quest the quest is if there are a way to do it in a
> cross-platform way using pinvoke and whether that way works well
Sorry for joining your discussion, I'm quite newbie in C#/.Net/mono :),
but maybe our Java experience will help you.
We had exactly the same problem in Jaybird
Hello:
> I've tested this and works!
If it works we can try to add it to the 2.1.0 sources ...
huu i will try to try to take a look at that today or tomorrow
-
Take Surveys. Earn Cash. Influence the Future of IT
Join Sou
> If you use fbembed.dll, then you can use it like a client to "normal"
> server too. The hint about Mono and different FB servers isn't clear to me.
1) I can use FB 1.5 ebbedded and normal FB 2.1. And i think that
fbembed.dll from 1.5 will not fully support all futures of 2.1
2) As i understoo
> > I've tested this and works!
>
> If it works we can try to add it to the 2.1.0 sources ...
> huu i will try to try to take a look at that today or tomorrow
No need to rush it in to the 2.1.0 branch if it's going to cause problems.
:)
One thing that someone probably needs to do is take a l
sasha wrote:
> 1) I can use FB 1.5 ebbedded and normal FB 2.1. And i think that
> fbembed.dll from 1.5 will not fully support all futures of 2.1
Of course.
> 2) As i understood from sources windows "fbclient.dll" called
> "libfbclient.so" on linux, so for same mono program i'll need different
Hello,
sasha said the following on 28.02.2007 12:07:
> 2) As i understood from sources windows "fbclient.dll" called
> "libfbclient.so" on linux, so for same mono program i'll need different
> versions of provider for windows and linux.
It is not the case, as mono provides a library mapping me
Hello:
> No need to rush it in to the 2.1.0 branch if it's going to cause problems.
> :)
Not a great deal, i can wait to have that changes on the svn tree and do
the release then ( probably of a new beta )
> One thing that someone probably needs to do is take a look at what I did
> with FbConne
> It is not the case, as mono provides a library mapping mechanism:
> http://www.mono-project.com/Interop_with_Native_Libraries#Library_Names
It's interesting - thanks...
-
Take Surveys. Earn Cash. Influence the Future of I
Hello:
> I had a go, and it wasn't all that difficult. I've uploaded the files that I
> changed from FirebirdClient-2.1.0.0 Beta1 (which was the version I had)
> here:
>
> http://codeka.com/tmp/fb-beta1-updated-files.zip
>
I have that sources megred on my local tree hope to be doing some
testi
Carlos Guzmán Álvarez wrote:
> I have that sources megred on my local tree hope to be doing some
> testing as soon as possible :)
My tests on my were OK.
--
Jiri {x2} Cincura
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
-
Jiri Cincura wrote:
> My tests on my were OK.
>
He wants to say "... on my tree were ..." ;)
--
Jiri {x2} Cincura
http://blog.vyvojar.cz/jirka/ | http://www.ID3renamer.com
-
Take Surveys. Earn Cash. Influence the Future of
Hello:
> He wants to say "... on my tree were ..." ;)
Ok, i willt ry to see if some change is needed in the
FbConnectionStringBuilder class, and in any other place too
( maybe for the external procedure engine GDS, while
i'm not sure on continue to mantain this as i don't know what is
the state
Hello:
> I had a go, and it wasn't all that difficult. I've uploaded the files that I
> changed from FirebirdClient-2.1.0.0 Beta1 (which was the version I had)
> here:
>
> http://codeka.com/tmp/fb-beta1-updated-files.zip
Changes are in SVN now.
--
35 matches
Mail list logo
