Hi Jeff,

First of all, thanks a lot for this great project! I already gave you my opinion in a review, but I want to congratulate you again because DotRas rocks!

"This project is pure excellence. Extremely well documented, follows almost all C# nomenclature guidelines, and, of course, provides a very intuitive and, above all, thorough API. Thank you very much!"

Here's my problem:

I set the following properties on a RasEntry:

• Options.RemoteDefaultGateway = false
• Options.DoNotUseRasCredentials = true
• DnsSuffix = "someString"

and then call Update on it.

Everything works fine, but when I go to the properties of the VPN connection, the "Internet Protocol Version 6 (TCP/IPv6)" checkbox is unchecked on the Networking tab (it was checked by default).

I have already seen these three issues which seem related:

• http://dotras.codeplex.com/workitem/14663
• http://dotras.codeplex.com/workitem/14664
• http://dotras.codeplex.com/workitem/14665

but they are marked as resolved and I'm using the latest version (changeset 96926), which I compiled myself as a non-official release (without a strong key or certificate).

Not that this really bothers me, but it might cause trouble for someone.

Is there anything else I can provide to you to diagnose?

Thanks in advance,

Gabriel

The issue was found with the 1.2 release of the product, and as indicated on those work items has already been patched, it just hasn't been released. Due to the timing with the Windows 8 launch, there wasn't enough time remaining to warrant a service pack release which would have included my usual 6 month freeze on the code to find any outstanding bugs before the release.

Are you saying the latest changeset still experiences the issue? The issue should be resolved in the Trunk code base right now.

Jeff,

Thank you for your answer.

Yes, I am experiencing the issue with the latest changeset 96926 (at least it was the latest yesterday), built from trunk.

Something I found when building the source, is that the output was placed in the folder "TempBuildDir", inside "Trunk", and not in " .\Output\Bin" as stated here. Could this have anything to do?

Let me know if I can facilitate you any test data to repro.

Thanks

You probably just didn't provide some of the parameters which change the output path to the Output folder as specified on that documentation page. The files in the TempBuildDir is where everything gets staged while being built. If you don't specify the /skippack switch to the make.bat/make.cmd the files get left there since the output path hasn't changed, so it assumes you're going to try to pack it into the MSI but it can't because documentation wasn't built. Using some of the switches while not using others just gets it left in an inconsistent state which causes it to leave the files. I wouldn't worry about where you picked the files up from, those would be the same files as would have been in that other folder.

What operating system(s) are you experiencing the problem with?

What build flavor are you using on the operating systems? (WINXP, WIN2K, WIN2K8, WIN7, WIN8, etc).

Since you're using a custom build, you're going to have to make sure this is correct. If it's wrong, I might not be able to reproduce it.

Thanks for your answer, and I apologise for taking so long to get back to you, I've been too busy.

I confirm that I can repro using the WINXP flavour (built from changeset 96926) on Windows 7 Ultimate SP1 x64 and Windows Server 2008 R2 Enterprise SP1 x64.

I tried setting the value of each of the properties I mentioned (RemoteDefaultGateway, DoNotUseRasCredentials, DnsSuffix) independently and concluded that any of them uncheck the IPv6 checkbox.

Could this be because XP does not have support for IPv6 and I'm using the WINXP flavour?

I hope you can repro.

Thanks

I'm about 99% sure that the problem is because you're using the WINXP flavor of the DLL. Try changing to the WIN2K8 version which is Windows Vista and the Windows 2008 Server version of the assembly. You'll lose Windows XP support if you do, but you'll have access to the IPv6 functionality.

I'll check it tonight when I get home, but that'll probably take care of the issue.

You are right, I tried the WIN2K8 flavour and the IPv6 checkbox did not get unchecked.

I'm not using IPv6 functionality, I just do not want to alter any settings configured by a user on his own VPN connection (which might need IPv6). However, I do not want to lose XP support just to gain this.

Is there anything you can do to DotRAS to fix this? Or is it a problem with the WinAPI? If the latter, can I make a call to the API to set the value to its previous state (I would need to read it first, of course)? I'm guessing that it is very likely that any other settings which were not supported by XP are getting overwritten, so perhaps it is too much work to keep track of all those values to restore them later. What do you think?

Thanks!

The problem is definitely inside the Windows API, it is most likely overwriting the information because it does not default to leaving it alone if the struct size does not match the flavor that's running on the box. Like it says in the documentation, the DLLs used by Windows are not backwards compatible. They may work in a forward compatible scenario, but things like this will be a problem. Right now, you're trying to use support both a platform that does not support IPv6, and also support a platform that does support IPv6. You'll need to work out how you intend on deploying your application to make sure that, depending on the box, you can deploy the correct flavor of DotRas. This would be very specific to your environment, so you'll need to figure this part out on your own. Basically, you need to find a way to deploy the WINXP flavor on your Windows XP boxes, and deploy the WIN2K8 flavor on the Vista and later machines.

Personally, I'd probably just build a WiX package that includes both versions of the DLL and swap it out on install rather than building different flavors of your app that uses the different DotRas flavors. Or perhaps it really doesn't matter because you're going to be modifying their entry connection anyway, if you weren't modifying the phonebook entry I could see myself being concerned that I'm changing the setting, but if you're already modifying the entry from settings the user may want set on the entry does it really matter if it clears the IPv6 setting? Just a thought. :)

- Jeff

Jeff,

Thank you very much for your thoughts.

I guess I could reference the XP version to get my app to compile, but keep that dll and the other one (or perhaps all the others) in a sub directory, so that the CLR does not automatically load it, and then subscribe to the AssemblyResolve event to load the right dll for the current OS.

But for now I will keep it simple and just stick to referencing and using the XP version. Sometimes one has to be pragmatic and focus on solving what needs to be solved, and I think that clearing the IPv6 setting will not affect my users.

Thanks again for your help.