I did not include any internet service in my program. when i choose deny access internet, it can not run and windows reports a error.
permission to access internet will run it perfectly. i am confused...
Printable View
I did not include any internet service in my program. when i choose deny access internet, it can not run and windows reports a error.
permission to access internet will run it perfectly. i am confused...
The early version of my program can run without access internet . The only change of new version is I have a button to change the form size.
the code like this:
me.size = new size [x,y]
help me...
Is it a ClickOnce application, i.e. did you publish it to create an installer?
did you check off the option to make your application a "single instance application" in the project properties screen?
If you did, which is pretty common to do, then this can happen.
The issue why is not so well known though. Assuming this is your problem, I will share the reason why. Setting that options makes the framework create a remoting channel via TCP on the system. This remoting channel is local to the system, but still uses the standard TCP stack to do its communication.
So when the first instance starts up, it creates the channel and starts listening. Then when you start a second instance, it hooks up to the same channel and knows an instance is already running, so all it does is sends it command line params to the first instance (if there are any) and then it shuts down.
Well the problem is that some firewalls capture the channel request and block it unless you allow it. The problem is worse than that, because if it is blocked, a socket exception gets thrown which is not catchable by your app, even if you wire up an unhandledexception event handler. This is because this TCP wireup code happens before ANYTHING else in your app.
MS is aware of the problem because I filed a bug report, however they postponed the fix, so who knows when there will actually be one. Here is a link to the article outlining the details of this issue:
https://connect.microsoft.com/Visual...dbackID=298407
So as far as a workaround, it depends on the version of .NET you are using, and what versions of Windows you want to support.
Bill McCarthy wrote a nice article on using named pipes which performs the same function as single instance app, but without TCP remoting. However named pipes are a new class to the 3.5 framework
http://visualstudiomagazine.com/colu...torialsid=2331
I wrote a workaround for this issue using the IPC (InterProcess Communication) classes, which are similar to TCP remoting, but since it is IPC, communication can only happen on a single machine and can't contact a remote machine, no firewall is invoked and no TCP channel is used. However IPC doesn't work on Windows 98 or ME (even though docs say otherwise).
There are other ways to accomplish single instance applications, however if you ever need command line args passed between instances, that is usually where the challenge lies.
Why have MS just closed the case when they admitted that there is a bug in their software that they cannot even find a workaround for :S grrr.
Yes, I check off the option and make my application a "single instance application".
I will cancel the option and report it here later.
I do not creat a installer for my program since most of people hate the installation. I know without installation the referenced dll in my program is a big problem if i run it in other computer.
So I just wondering is there a munual way to register those dlls. [in the program or outside of program]
I tried something like regsvr32 "C:\....\ *.dll " in the run prompt, and the register successed. but program still can not find required dll.
Is it possible to put some vb.net code in program like : find (or reference) *. dll in c:/..... ??
well when I spoke to someone about MS as to why they even used such an expensive thing like TCP remoting for such a trivial feature like a single instance app, they said there was a good amount of debate, and a TCP remoting channel was the winner as to how they were going to do this. They said it was a combination of security needs and functionality, and also something that would exist on all versions of Windows that the framework needs to support.
As far as the bug being fixed, it generally comes down to life cycle of the framework and when they can develop, test, and push out a fix, without disrupting the existing code base that people are using. If they are going to introduce a breaking change to the framework, they need to fully evaluate it to see how bad it will affect users. So we might see this fixed in .NET 4.0, but never see a fix back ported to an existing framework version.
Likely in future frameworks, TCP remoting won't be the method of single instance application handling, because future frameworks will only run on Windows systems that have newer features (like WCF or something) and they won't be limited by the need to be compatible with 98, ME, and Windows 2000.
If you want, I can post a sample of my IPC code, however as I mentioned, it doesn't work on 98 and ME. What I did for that scenario, was I still only allow 1 instance on 98 and ME, but I just don't handle passing command line params to the already running app.
Then I would say there is a very good chance that option is what is causing your firewall to prompt for access. If you look at the details of the firewall though when it does prompt you, it likely is telling you it is connecting to a local IP like 127.0.0.1 (loopback address).Quote:
Originally Posted by stripling
as far as your DLL issue, what types of DLLs are these (com based, .NET based)? Making an installer would likely be your best bet unless you are only planning on rolling this out on a very small amount of machines?