first strange bug

Hi Karl,

After some testing the problem was due to the obfuscator we use (Dotfuscator). When testing with unobfuscated code, it would work fine. We upgraded to the newest Dotfuscator version that just came out (of which a feature of it says improved Vista support) and tried that. It seems to have resolved the issues.

There are now new maintenance releases of all our products available on our site. Please upgrade to the latest maintenance release to solve this issue.

wow, that was soo fast.. glad i posted last night before bed.. will tell you how it goes.

i have rebuilt with .217, and verified that those are the assemblies come over, and its still taking time (one time it took 5 minutes) to load up.. and also i just made a very simple app (just dropped the componennt on a form) and in vista,

it took about 3 or 4 minutes to come up.

i'm going to also create some other sample applkications to see if i can future diagnose, (i.e loading the control dynamically when the a button is clicked).. but it seems like the latest upgdate didn't help anything... At first i think maybe another commercial control i use also used dotfuscator and had the same problem, but i made a sample app putting their visual controls on it, and it loaded fine.. and of course my simple app, where i just dumped a syntax editor on is failing on my vista

if you need access to my system to help diagnose this it can be arranged.

-Karl

NOTE I EDITED THIS: the first time i didn't copy accross the DLLs

[Modified at 02/04/2007 05:34 PM]

yep another confirmation, again using .217

i just have a project, referncing the actipro DLLs, a form with a button, and i dynamically create a syntax editor control.. so the form comes up right way, but the 3 - 5 minute wait occurs when i press the button..

below is the relevant code from this simple project..

---------------------------------
private void button1_Click(object sender, EventArgs e) {


loadsyntaxeditorcontrol();


MessageBox.Show("after");

}

private void loadsyntaxeditorcontrol() {
ActiproSoftware.SyntaxEditor.SyntaxEditor syntaxEditor1;
syntaxEditor1 = new ActiproSoftware.SyntaxEditor.SyntaxEditor();
this.Controls.Add(syntaxEditor1);

}
------------------------------------

Hi Karl,

Hmmm... I'm not convinced you are using the new release. The reason I say so is that I was able to duplicate your issue with build 216 on a VirtualPC with Vista on it. Then after making the changes and putting on build 217, it worked there. And after your postings last evening where you said 217 didn't help, I installed build 217 on another "clean" Vista box that has VS 2005 on it. I opened the solution in VS, ran the program and the editor came up just as you would expect, like in XP.

I'm wondering if perhaps you installed/referenced the new build but for some reason (maybe caching) it's still pulling in the old builds. Did you uninstall build 216 before installing 217 and follow the other steps in the Licensing FAQ for upgrading? Also, when you run our sample project if you are able to get into the MainForm sample at run-time, click Help/About and that will tell us what build you are really running.

Again, I was able to duplicate your issue with build 216, but after installing yesterday's build 217 on two separate Vista machines, I did not see the problem occur any more.

Can anyone else out there who uses Vista also try out build 217 and let us know if it works fine for them? As always, uinstall the old build before installing the new.

If there is still a problem, we definitely will try and fix it as fast as possible.

Karl,

Some more info... I just had another couple of customers try build 217 on Vista and they say it also comes up very fast like it should.

I started running my app on Vista with the releases prior to the current maintenance releases. Even then, I didn't experience any of the problems Karl is seeing. My tooltips always appear in Syntax Editor, and my app would load quickly every time. I updated to the latest maintenance releases, and everything still looks good.

The machine I'm compiling on was a clean install of Vista Ultimate 32-bit where everything was setup for the first time. Perhaps the issues being seen are related to old assemblies or configuration settings lingering around. Not sure if it makes a difference, but I always run Visual Studio 2005 as an administrator.

thanks for your diligence.

a few things.. there is no visual studio on my vista box.. its pretty much a plain install,other than i previous have had vmware on it.. so i copy the files accross and verify that they are actually 217.. also since my project is a live interactive enviroment, from within my application i can run commands, so i ran this line here, which showed me the assemblies currently loaded in the process..

[system.AppDomain]::CurrentDomain.GetAssemblies() | ? { $_.fullname -match 'actipro*' } | Select-Object fullname > c:\karls\actipro.txt

which yeilds these results

FullName -------- ActiproSoftware.SyntaxEditor.Net20, Version=3.1.217.0, Culture=neutral, PublicKeyToken=0ecd8d0e8818ec9b
ActiproSoftware.Shared.Net20, Version=1.0.87.0, Culture=neutral, PublicKeyToken=36ff2196ab5654b9
ActiproSoftware.WinUICore.Net20, Version=1.0.87.0, Culture=neutral, PublicKeyToken=1eba893a2bc55de5

which convinces me i'm using the right build.. (and on the dev machine, i did uninstall version 216, and after installing 217, i had to fix up my references in the project..

a few things to note....

this is a domain computer, that has my documents on a corporate share, however as a laptop its syncrhonized, so its availible offline
there are other corporate shares mapped through group policies, these of course are unavailible when offline.

things work fine (it comes up right away) under the following circumstances..

1) When i'm plugged into the corporate network..
2) When i disable all networks/adapters (i.e at home, i turn my wifi OFF) it all works

however it doesn't work when i am not on the corporate network and there are active networks (i.e a wifi connection, and before the network adapters from vmware when that was installed)

one thing i haven't tried to help isolate this, is if it works under the "bad" circumstances, if i log in as local admin rather than with a domain user.. i will try that next.

My first tests with the 217 build on our Virtual PC Vista were the same as you. I copied the sample project over along with the obfuscated assemblies. With build 216 I saw the issue you described. With build 217 I no longer did.

SyntaxEditor does not do execute any sort of file access or network access code unless you do something that would trigger such an action. Such as trying to load a document from a file or a language from an XML definition. So I'm a bit baffled why network access is making a difference in your case if you have a vanilla application that doesn't load any files.

In past experiences with older versions of Windows, whenever things would come up slow (just apps in general and not dealing with our software), it would generally be a networking issue. Sometimes old versions of Windows would lock up while locating the network and then resume after the operation was complete. I wonder if something like this is happening in your scenario. However again, I still don't understand why putting our control on a Form would cause it since we are not loading files without you telling us to do so.

well i believe the bug is fixed in 217.. today i rebooted the machine , and now it is working, so the issue must have been something to do with 216 and dotfuscator and was lurking because i didn't reboot.. but it was very strange nevertheless...

the reason why it was when i put the control on the form, i believe was bedause of dotfuscators issue, and dotnet will load the assembly and compile the p-code into native in memory when you first need /reference a type in the assembly.. which on the form is right when its trying to load.. the reason it worked different in my other example (creating the control dynamically on button click) is dotnet doesn't need to load/compile to pcode until i hit that button.

i'm just glad its working now.. now onto the other issue.

Ahh good... glad that did the trick.

well :( sadly that didn't do the trick, that reboot just lucked me out with the right network enviroment.. i've had this happen again and again, and i can get it to work normal, take forever, just by switching my wifi connection on and off.. also its definately syntaxeditor for the behaviour is 100% consistant in my test app that is purely a form with syntaxeditor on it.. and its definately version .217.. Also some other users are getting the same error. I'm currently sending out a build to my beta testers with a questionare on behaviour and hopefully i can provide more accurate information for you.

:(

this is one of those horrid problems.

I really am drawing a blank on why this would even happen since we're not hitting the network and can't dupe it here.

Please try this for me... make a new application with a Form and put a Button on it. In the button click event handler, simply have this line: Let us know if the slowness happens either at the application start or when you click the button. We need to narrow down what exactly is causing this. Thanks.

in fact that is what i had done in one of my demos.. its basically when dotnet tries to reference and compile the assemblies to pcode.. its when the class that references and creates the syntax editor control is loaded that the slowdown happens, in one of my demos it happened like that, press a button, and under good networking enviroment, it happens instantaneously , other times it can take a number of minutes..

also another note, at different times i've tried to NGEN your assemblies (however my tests are with assemblies that are NOT NGEN'd).. and when i try to NGEN them, when i have my wifi connected, each one takes a long time as well..

one thing i can test though is ngening them, and see if they are fast After that. one thing to note, the ngening was slow on each of your 3 assemblies..

Let us know what you find there with the pre-NGENed assemblies. And if it works fast after the NGEN, the next thing I would think we should look into is the possibility that the obfuscator we use is causing the issue.

pre NGEN'd doesn't make a difference.. whenever i have a project that references syntaxeditor it does this under certian circumstances.. sometimes.. and i've put a wide beta out, and its similar. some users don't have any problems, some have it all the time, and others just sometimes...

i don't know where we can proceed. i doubt you want to have unprotected assemblies out there to the public. i don't know if you want to provide those to me, in a way i can copy over and see if it makes all the difference on my own vista or not...

my own next step is implement very detailed logging in my own app, so i can help narrow things down

Hi Karl,

Would you mind working with us via e-mail on this? I'd like to try a number of things with you if you are willing so that we can try and narrow down the problem and sort it all out. If you would, please send our support address an e-mail and reference this post. It would be much appreciated. Hopefully by trying a lot of things we can narrow down the cause and figure out how to work around it.

If we could dupe it here we could work on it ourselves but unfortunately it just isn't happening for us or the other customers we regularly speak with.

After a lot of testing of various builds with Karl, we found that this issue is occuring when the assembly is code-signed and .NET is attempting to verify the code signature.

We located a newsgroup post on this here:
Newsgroup post

From an MS person's reply in that thread:

Quote:
Yes, the delay at the start time is due to the CLR make verification against the certificate info in the assembly. However, .NET CLR calls WinVerifyTrust internally and the problem is that WinVerifyTrust does not allow for specifying a timeout for revocation. So the problem is actually due to the WinVerifyTrust of the windows system
rather than the .net runtime system. I've asked our PKI folks and they said they might add such flags to control default timeout in a post MS04-11 QFE and W2K3 SP1.

We're still trying to figure out what else we can do related to this.

Now that we've isolated what is causing it, I'm able to do cleaner searches on the issue and am finding more info...
National Instruments thread related to this same issue

In there they provide this same possible workaround, which is not really a workaround because it turns off all checking on that particular machine and only works on that machine.

Quote:
The workaround they presented was to disable Certificate Revocation checking by disabling this option in Internet Explorer.

1. Launch Internet Explorer and go to Internet Options
2. Click on the Advanced tab
3. Scroll down to the "Check for publisher's certificate revocation" checkbox and uncheck it.

By disabling the CRL checking using the IE options, you are not exposing yourself to a security threat because this check is not working for you in the first place. The reason why this problem is showing up is because your network settings are not allowing the Windows Public Key Infrastructure (PKI) system to access the CRL.

Here is another detailed post on this issue.

Another possible workaround from that page is this:

Quote:
Open up the server's firewall enough to let the blacklist server query succeed.

In our case, this should be to crl.thawte.com.

I also read another control vendor's (Xceed) post about how they gave up and stopped signing because there is no viable workaround for this bad security design. It sounds like that might be what we have to do as well if nothing else comes up as a solution.

[Modified at 02/18/2007 05:21 PM]

After looking at this more, I think we are going to have to do like Xceed and just remove code signing from our assemblies. It is very frustrating that something that is supposed to make a product more secure is unusable because of these delays that Microsoft creates in certain scenarios.

The next releases of our controls that have a Shared/WinUICore update will no longer have code signing on the assemblies.

Thanks for working with us Karl to sort these issues out.

[Modified at 02/19/2007 07:03 AM]