Stop triggering firewall on Windows? Preset build path?

[Karl Macklin]

I'm developing Go in Windows 7.

Doing a simple http listening program, listening on port 80, or 8080, or whatever.

When I do go run my program it triggers Windows 7 firewall to pop up and ask if I want to block or allow main.exe to have network access.

Usually you can let it have access and you wont get the question the next time you compile and run it. However, everytime the code it built a new path is generated, looks something like this:

C:\wintemp\go-build053100907\command-line-arguments\_obj\exe\main.exe

(wintemp = my windows system temp folder)

So even if I accept the network at this point, the next time I run it, it may have another path:

C:\wintemp\go-build092553123\command-line-arguments\_obj\exe\main.exe

And yet again you must accept to allow network access.

So - what to do? I tried turning off the Windows Firewall.

Is there a way to set a constant preset build path to solve this? Or could that break something else?

[Jan Mercl]

On Tue Feb 10 2015 at 9:26:08 Karl Macklin <ka...@delorean.se> wrote:

> So even if I accept the network at this point, the next time I run it, it 

> may have another path:
> C:\wintemp\go-build092553123\command-line-arguments\_obj\exe\main.exe

>
> And yet again you must accept to allow network access.
>
> So - what to do?

Stop using go run as a development tool. It is not.

-j

[Karl Macklin]

Ok, what should I use instead?

[Egon]

I'm using gin to automatically update my binary. You can also use go build && appname.exe, that way the exe stays the same.

Also you can add a "local debug server" rule to inbound firewall rules - i.e. allow any program for port 8080.

[Konstantin Khomoutov]

On Tue, 10 Feb 2015 00:50:59 -0800 (PST)
Karl Macklin <ka...@delorean.se> wrote:

[...]

> > > And yet again you must accept to allow network access.
> > >
> > > So - what to do?
> >
> > Stop using go run as a development tool. It is not.
> >

> Ok, what should I use instead?

`go install` or `go build`

The first invocation build the project and installs the result
(in your workspace hierarchy), the latter builds the project, discards
intermediate results and places the resulting binary in the current
directory.

Please read this thread [1], and [2].

Also please read the results of running `go help install` and
`go help build`.

1. https://groups.google.com/d/topic/golang-nuts/50wO63bZ7rc/discussion
2. http://dave.cheney.net/2014/06/04/what-does-go-build-build

[Karl Macklin]

Thanks for the answers, install and build both seem useful.

Egon - how do you use gin do to this?

[Egon]

On Tuesday, 10 February 2015 12:37:28 UTC+2, Karl Macklin wrote:

Thanks for the answers, install and build both seem useful.

Egon - how do you use gin do to this?

Essentially gin already internally does the "build" & "run application" from the same location, also I like that it automatically reloads when I change code. (https://github.com/codegangsta/gin)

+ Egon

[Daniel Theophanes]

Just open ports 80 and 8080. Don't restrict by program, just open the ports.

[Florin Patan]

Hi,


Can you please clarify why go run is not a development tool? Is there a link with a proper detail from the go team?

Thank you.

[Tamás Gulácsi]

With go run,
- you have to specify all the package .go files, or use only one, and loose the ability to organize your code into separate files - use go build
- every time recompile everything, as it doesn't cache compiled packages in $GOPATH/pkg - use go install

[Mateusz Czapliński]

Or, I believe "go build && myappname.exe" (as mentioned by Egon too) is on par with go install, with the small difference between the two (i.e. location of the resulting executable) left up to personal choice/preference/needs.

/M.

[Florin Patan]

Hi Tamas,

I have yet to encounter the issue you are describing with go run.

All my apps are go get-able and I can always run them with go run file_with_main().go

Also I've never encountered issues if I have more than one file with main() declared, all on the same level.

I'm asking these questions because I want to understand the issues as I'm contributing on the Go plugin for IntelliJ IDEA and it would be helpful to understand the conditions you are describing as I've never encountered them in my work so far.

Thank you.

On Wednesday, February 11, 2015 at 6:34:13 AM UTC+1, Tamás Gulácsi wrote:

[Egon]

On Wednesday, 11 February 2015 12:26:48 UTC+2, Florin Patan wrote:

Hi Tamas,

I have yet to encounter the issue you are describing with go run.

All my apps are go get-able and I can always run them with go run file_with_main().go

Also I've never encountered issues if I have more than one file with main() declared, all on the same level.

This happens on windows because,

"go run" always creates a new temporary executable. Windows detects that as a completely new program which doesn't have any firewall rules set, i.e. Windows then asks whether to open ports for that program or not.

go build / go install, create the file in the same location, which means that the windows doesn't treat it as a new executable and already has the necessary firewall rules after first confirmation.

+ Egon

[Jan Mercl]

On Wed, Feb 11, 2015 at 11:26 AM, Florin Patan <flori...@gmail.com> wrote:
> I have yet to encounter the issue you are describing with go run.
> All my apps are go get-able and I can always run them with go run
> file_with_main().go
> Also I've never encountered issues if I have more than one file with main()
> declared, all on the same level.
>
> I'm asking these questions because I want to understand the issues as I'm
> contributing on the Go plugin for IntelliJ IDEA and it would be helpful to
> understand the conditions you are describing as I've never encountered them
> in my work so far.

$ cat main.go
package main

import (
        "fmt"
)

func main() {
        fmt.Println(f())
}
$ cat util.go
package main

func f() { return 42 }
$ go run main.go
# command-line-arguments
./main.go:8: undefined: f
$

-j

[Nick Craig-Wood]

On 11/02/15 10:13, Mateusz Czapliński wrote:
> Or, I believe "go build && myappname.exe" (as mentioned by Egon too) is
> on par with go install, with the small difference between the two (i.e.
> location of the resulting executable) left up to personal
> choice/preference/needs.

If you have a big project you'll notice the difference in speed between
go build and go install. It is especially noticeable if you have
modified code in a package which you are not typing go build for - that
has to be rebuilt every time.

In my 25,000 line project split over 50+ files it takes about 2 seconds
for a cold build, but only 0.6s for a go install after that cold build.
go install speeds up subsequent go builds.

.../src/github.com/ncw/myproject$ rm -rf
~/go/pkg/linux_amd64/github.com/ncw/myproject
.../src/github.com/ncw/myproject$ time go build

real 0m1.972s
user 0m1.796s
sys 0m0.237s

.../src/github.com/ncw/myproject$ time go build

real 0m2.004s
user 0m1.797s
sys 0m0.255s

.../src/github.com/ncw/myproject$ time go install

real 0m1.955s
user 0m1.809s
sys 0m0.210s

.../src/github.com/ncw/myproject$ time go install

real 0m0.614s
user 0m0.531s
sys 0m0.085s

.../src/github.com/ncw/myproject$ time go build

real 0m0.960s
user 0m0.864s
sys 0m0.080s

--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick

[Aleistar Markóczy]

I may not be "using go run as a development tool" (which I would deem a perfectly fine reason to use "go run", I mean what else would you use it for, maybe to run on production? ;-) ) but the same happens when running go test to run tests while creating a server to run the tests on.

The trick of opening the port works perfectly file, thanks! Just open the windows Firewall Settings > Advanced Settings > Inbound Rules > New Rule > By Port.

[Egon]

If you use `127.0.0.1:0` as your listening address then the firewall won't trigger as well.

[Space A.]

Just was going to say that =)

суббота, 7 ноября 2020 г. в 23:01:17 UTC+3, Egon: