views:

190

answers:

4
+1  Q: 

Powerbuilder run

Hi,

I'm using Powerbuilder to call an external function from a DLL created in C#

If I generate an executable it works fine, it call the web service perfectly well, but when I'm trying to run it in "development" mode it don't use the "application_name.exe.config" file.

I tried to set "app.config" file hard coded in the DLL, but I was unsuccessful

Clues to resolve this issue?

A: 

DLL's dont have config files. Only EXE's.

leppie
Thanks for the reply's...
Actually, that is incorrect. Both DLLs and EXEs have config files.http://msdn.microsoft.com/en-us/library/aa374182%28VS.85%29.aspx
Bruce Armstrong
+1  A: 

I think you described it yourself: you're looking for it to use something used by the EXE when you're running from development mode. When you run from development mode, there is no EXE generated or used, so Windows won't be leveraging functionality linked to the EXE. (PB starts your application so quickly because it is only loading the application to the virtual machine and running its Open event.) If you need this, it sounds like you'll have to include Deploying of the EXE and running it as part of your testing cycle.

Good luck,

Terry.

Terry
Yep, it's something like that. I'm trying to prevent that, because full build and EXE generation of my application it's a 2 hours process.
Saying flat out that it's a 2 hour process makes it sound like you're exclusively using Full Build. While that's an approach I'd definitely advocate for final builds, have you tried experimenting with Incremental Builds? It's far more solid than it used to be, and like I said, I think you'll need an EXE build for testing that uses the config file. (I'll be happy if someone has something to add that proves me wrong.)
Terry
there is more than one person developing this application, and we use some objects inherited from others, so if PB starts with Incremental Build but encounters some errors, it will do a full build...tks for the reply.But I don't try it, because I don´t need it any more.
You should **NEVER** work off of shared PBLs, for that very reason! (And that is even less significant than the locking of PBLs when you run.) Setting up a PBNative source code repository probably makes sense (and is free). Yes, it will seem like extra work to check out/in objects, but the freedom you will gain to run, regen, etc... will be significant.
Terry
+ 1000 for "You should NEVER work off of shared PBLs". I've had to restore shared libraries more than once, one time from a backup that was over a month old (thanks, guys). AT THE LEAST, set up a PBNative repository. If you have a version control system that speaks MS' SCC API, use that if possible. We're currently running different projects using Merant/PVCS and TFS.
DaveE
A: 

When you compile and run from the exe you're using your exe. But when you run from the dev environment you're actually using pbxxx.exe (pb115.exe, pb110.exe etc.). You may be able to copy the "application_name.exe.config" into your pb directory and rename it something like pbxxx.exe.config. At least that's the way it works with manifest files -- I had two, one called appname.exe.manifest and one called pb115.exe.manifest.

Slapout
The solution that we find, was to put the configurations used by the generated EXE in the PB115.exe.config. And it will find what is needed to run properly. Thanks a lot for the answers..
A: 

Just curious but how many libraries/objects are in your application?

I have some very large applications and the longest any of them takes to do a full build is about 30 minutes. Something odd about your aapplication for it to take 2 hours to do a full build.

psant
FWIW, I've seen some objects take significantly longer (magnitudes) to regen than others. It might not be appropriate to try to extrapolate from one app to another, let alone from one build system to another. (PB build process tends to be pretty disk I/O bound, so slower disks will make a significant difference.)
Terry
134 Libraries, for now...