Devart Forums

I'm developing an application that uses dotConnect for PostgreSql and the Linq To Entities Framework 4. I built the entity model using Entity Developer.

When I first started on this application, the program would run fine, even if DbMonitor wasn't running. However, about 2 weeks ago, the program started dying if DbMonitor wasn't started. I was trying to fix an issue with the program not running under XP (I have another thread about that issue, and it's still not resolved, by the way).

Since then, I don't know what I did, but now the program generates the following socket exception whenever I start it & DbMonitor is not running:

No connection could be made because the target machine actively refused it 127.0.0.1:1000

I need to fix this as DbMonitor will not be installed on client machines when the program goes to production.

How do I fix the program so this error no longer occurs?

Thanks

Tony

The problem is that a PgSqlMonitor object tries to connect to the dbMonitor application, which is not available.

To resolve the issue, you can perform one of the following:
1) Disable the PgSqlMonitor instance. If you use the monitoring functionality for the testing purposes only, you can disable PgSqlMonitor in the release version of your product.
2) If you do work with PgSqlMonitor inside your application, you can set its UseApp property to false, so that it does not send message to dbMonitor.

Please tell us if this helps.

So what you're saying is the behavior I'm seeing now is normal and the behavior I saw in the past (where the program would run without complaining if dbMonitor wasn't running) isn't normal?

OK, I'll buy that. I suppose I can put the call into a try-catch block & just ignore the exception. And I can put the call to instantiate the object into a #if DEBUG....#endif block so it won't get called in release.

Does that sound OK?

Tony

These exceptions should be caught inside the PgSqlMonitor class. If you see them under debug, this may be because you've changed the Visual Studio debug settings to see thrown CLR exceptions (the Debug -> Exceptions item of the Visual Studio main menu). Please tell us if this is not the case.

As for the '#if DEBUG' block, this seems to be a proper solution.

I did change the Debug settings to break when CLR exceptions are thrown! I completely forgot about it!

I'll turn that setting off. That will fix it!

Thanks again!

Tony