Net access


I have a registered copy of GoDiagram. I’ve build a small test application and I was curious to note that the load time of my tiny application was slow. Then I noticed that when I fire up the app, the component seems to be accessing the internet behind the scenes. Can this be turned off? What’s it doing? Some of our apps need to run off-line so this “feature” is not desireable.


Northwoods.Go.dll does not have network accessing code in it, with the possible exception of GoImage when you specify an image file to read. Certainly there are no uses of System.Net classes.
You can confirm this yourself by looking at it what it calls. Since Northwoods.Go.dll consists entirely of managed code, it can even run in a reduced-trust environment, although perhaps with reduced functionality.
Two other customers have reported unusual slowness in startup for .NET applications. You didn’t say which versions of GoDiagram and .NET you are using. The Microsoft knowledge base has this report which may be relevant:

SYMPTOMS<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Programs that are developed by using the Microsoft .NET Framework are slow to load when you run the programs on a computer that is part of a domain.

When you double-click the executable file to start a .NET program, several seconds (sometimes as long as 30 seconds) may pass before the first form appears. This delay occurs with any .NET program, including console applications.


This behavior is caused by a bug in the .NET Framework runtime because some of the initialization code in the common language runtime requires the presence of an ASP.NET account. This problem occurs only on computers that are part of a domain.


To resolve this problem, obtain the latest service pack for Microsoft .NET Framework 1.0.


Thanks for the quick response. I’m working with .NET framework 1.1 and Visual Studio .NET 2002. My small C# application does absolutelly nothing yet - it has one Form onto which I’ve dragged one GoPalette and one GoView. Nothing else. The version of Northwoods.Go.dll is
I rebooted and re-ran the application and the same thing happens - a delay while the app connects to the net. While the app is running, if I do a netstat I get this:
Active Connections
Proto Local Address Foreign Address State
TCP xxxxxxxx:3097 CLOSE_WAIT
(the name of my machine changed)
If i remove the GoPalette and GoView from the form, rebuild and re-run the application launches immediatelly and it does not attempt to connect to the internet.


What happens when you try running any of the sample .EXEs that came with the installation of GoDiagram?
If you rebuild the samples (run BuildSamples.bat; the .EXEs get put in the GoDiagram root directory), which behavior do you get?


Ok I’ve rebuilt everything using the batch file and each of the samples contacts I’ve had a peek at the Northwoods.Go.dll with a hex editor and surprise, surprise it contains the string


That must get added when we signcode the assembly. Since we have to signcode our assemblies, I don’t know if there is a way for us to get around it.
What I don’t understand is that when I run on my laptop or on my desktop machine when they aren’t connected to the internet, everything works just fine, and without an apparent startup delay.
How long a delay do you experience? Is it about the same length each time? What happens when you disconnect your machine from all networks?


Thanks again. I had to reinstall VS.NET yesterday (arghh!) and it seems that this has resolved the problem. The delay I experienced was between 3 and 5 seconds.
Anyway - not a problem anymore.


We have the same problem on systems with just the run-time loaded. The systems are connected to a local network, woth a proxy/firewall blocking access to the internet.
We get a consistent 30 second delay the first time we start our application, this is due to a timeout accessing
When we disconnect the computer from the network the app starts immediately.
We only have the .net framework 1.0 installed, not
Is there anything we can do to eliminate this wait. I don’t think that reinstalling the framework would do much.



[EDIT: reference to obsolete kit has been elided]
contains assemblies that have been strong-named but not code-signed. You can include these assemblies in your delivered/deployed GoDiagram Win applications, instead of the ones that were installed by the 2.1.2 kit.
The problem is due to Verisign code that is inserted into the assembly/DLL when the assembly/DLL is code-signed. Verisign’s code is downloading a certificate revocation list, to make sure that our certificate (and perhaps others, including Verisign’s?) have not been revoked. Apparently the code does skip this check if it can easily tell that there is no network available, such as on a disconnected laptop, but if there appears to be IP/HTTP support when there isn’t access to, then it’s going to have to time-out trying.
Alas, we have absolutely no control over Verisign’s code. Strictly speaking, they are probably right in always having to check certificates, if the user has set the options to do such checking. Strongly named assemblies that are not code-signed are not verifiably identifiable to be from who they claim to be from, and thus are less secure than code-signed assemblies.
If you really need to distribute the code-signed assemblies, the folks at Verisign wondered if you could avoid the startup delays by turning off some of the Security options in Internet Explorer. I would try the ones in the Advanced tab under the Security category: “Check for publisher’s certificate revocation” and maybe “Check for server certificate revocation” or “Check for signatures on downloaded programs”.