This project is read-only.

Error enum

May 28, 2009 at 8:06 PM

Is it just me failing to find it, or has the enumeration of RAS errors that existed in the 0.3370  (or something like that) version of DotRas gone away as of the 1.0? (I finally upgraded my project, as after all we're nearing a release of the system ...)

May 29, 2009 at 1:39 AM

They're no longer exposed to comply with Microsoft's guidelines for creating interop assemblies. I also did it to shrink the size of the assembly since I had an enum with 200+ values that I was only needing 4 or 5 of them inside the assembly. It was also causing a lot of problems for StyleCop, which is why I moved them into the NativeMethods class and changed it to internal. That class name is a reserved name which allows me to bypass the StyleCop rules to match what is used inside the SDK header files.

Which errors were you watching for, and why were you watching for them?

More than likely you won't need to watch for them anymore. I just want to know so I can point you in the right direction where to look for the exposed functionality.

May 29, 2009 at 2:23 PM

Just a few:

- authentication failure (currently RasException.ErrorCode = 691)

- line busy (676)

- no answer (678)

- no dial tone (680)

- no modem (797)

and the "everything else" case.

I process them by catching RasExceptions thrown by RasDialer.Dial()

May 29, 2009 at 4:09 PM

I'd suggest just defining the integers yourself, that way your application isn't being bloated by 200+ values that aren't actually used anywhere. The biggest issue with the enum, was when using an assembly built for an earlier version of Windows and then using it on a later version the enum values weren't translating properly.

Scenario:  You use the WIN2K build for cross platform compatibility and deploy that assembly on a Windows Vista machine. The Vista machine throws a RasError that was not defined in the enum, because the WIN2K build did not have the enum value defined. That value comes across as 676 instead of being converted to the enum value.

Another scenario: Some time in the future, more error values are added and the enum is never updated (which is highly likely if you're thinking 5+ years in the future). You're now stuck in the same boat as the previous scenario because I didn't notice the enum needed to be updated.

That's why I made those changes. I marked the old assembly as CTP on purpose because I wasn't 100% sure the direction I wanted to take with things like this to ensure long term survivability of the project. I don't take changes like this lightly, if I do plan on making a breaking change be ensured that I have put a lot of thought into why I would have to. Since the project is now out of CTP, breaking changes like this will be few and far between unless I'm having to completely redesign something.