Inetc plug in ошибка

Interesting… it works for me. Is it working now?

Bringing up that this is still an issue (and one I believe I reported a while ago?)

https://prnt.sc/jrbrwu

This user reported that he has a download speed of 50kbps and a pretty bad connection…so I guess the plugin needs some upgrades to handle bad connections a bit better?

Still having users report this as a problem. Maybe there is a fix in a newer version @develar ?

I ran into this issue and it turned out to be a http/https issue. Here’s how I resolved it (for future finders):
In my package.json:

Notice the http part — for https I expect valid certificates to play a role in success/failure.

The web server had these files:

latest.7z is a copy of my latest build produced from npm run dist

Hope this helps!
Thanks @develar !

how can i solve this issue? thanks

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Same error. My case is because of wrong time. Update windows time fix it!

I identified one possible cause my users were having…they didn’t have TLS 1.2 enabled and we force 1.2 for our HTTPS connections.

Just noting it here in case it helps someone else.

Hello everyone,

I have this problem today with this version of packages :
«electron-builder»: «22.13.1»
«electron-updater»: «4.3.9»

I have the exact same error message which is «SendRequest error», which seems to be related with the inetc plugin.

Here is the «build» part of my package.json file.

"build": {
        "publish": [
            {
                "provider": "generic",
                "url": "https://my-website.com/download"
            }
        ],
        "appId": "com.app.test",
        "win": {
            "target": "nsis-web",
            "icon": "src/images/icon.ico"
        },
        "nsisWeb": {
            "oneClick": true,
            "perMachine": false,
            "include": "build/installer.nsh",
            "deleteAppDataOnUninstall": true,
            "allowElevation": false,
            "allowToChangeInstallationDirectory": false,
            "createDesktopShortcut": true,
            "createStartMenuShortcut": true,
            "shortcutName": "My Shortcut Name",
            "runAfterFinish": true
        }
    }

My web server is an enterprise web server with HTTPS valid certificate. The CA of this certificate is a internal CA.
Do you think this can be related to the error I have today?

Is it possible to reopen this case?

Best regards.

Just wanted to add my +1 to this issue for nsis-web.
My coworkers and I have not come across this ourselves, however a large amount of our users are coming across this error. Unfortunately, most that have come across this are not tech savvy, and so it’s a little difficult for my team to track it down.

We’ve noticed that while we haven’t really heard of this for our North American users, our Brazilian users seem to be the ones who run into this most often, then followed by some other South American countries, and a handful elsewhere in the world.

We’ve tried to change from https to http, but that’s only fixed it for a few of our users, plenty still have this error.

It may be related to timeouts? If the connection takes too long to establish to the servers, INETC may be timing out. Which may be the issue for some of those regions, from our sparse ability to test out hypotheses, though it would need to be confirmed. Perhaps a longer timeout might help (possibly around 30s-1m?), as a waiting a bit for an install isn’t overly problematic.

I’m also not entirely sure if there’s a way for us to modify the timeout duration ourselves. If anyone knows how, it might help us better test out the timeout hypothesis.

Just to give you more information, I fixed the issue by using nsis target instead of nsis-web, with these settings:

{
    "build": {
        "publish": [
            {
                "provider": "generic",
                "url": "https://my-https-website.com/download",
                "channel": "latest",
                "useMultipleRangeRequest": false
            }
        ],
        "appId": "app.test.git",
        "win": {
            "target": "nsis",
            "icon": "src/images/icon.ico"
        },
        "nsis": {
            "oneClick": true,
            "perMachine": false,
            "include": "build/installer.nsh",
            "deleteAppDataOnUninstall": true,
            "allowElevation": false,
            "allowToChangeInstallationDirectory": false,
            "createDesktopShortcut": true,
            "createStartMenuShortcut": true,
            "shortcutName": "My Shortcut",
            "runAfterFinish": true
        }
    }
}

Here are my packages versions.

"electron": "15.3.0"
"electron-builder": "22.13.1"
"electron-updater": "4.3.9"

It is more link a workaround because nsis target is not downloading the .7z package file on installation. But in the case this issue is not resolved, I hope this can help some of you.

Best regards.

We’ve also opted to go with nsis instead of nsis-web. However, for differential updates, this does imply that the amount to download is doubled, whereas this wasn’t an issue for nsis-web.

We’re currently programmatically separating 32 and 64bit packaging right now to generate two separate installers of nsis as a result, as by default they’re combined for a single 32/64 installer otherwise.

A solution to this nsis-web issue would be preferable.

Interesting… it works for me. Is it working now?

Bringing up that this is still an issue (and one I believe I reported a while ago?)

https://prnt.sc/jrbrwu

This user reported that he has a download speed of 50kbps and a pretty bad connection…so I guess the plugin needs some upgrades to handle bad connections a bit better?

Still having users report this as a problem. Maybe there is a fix in a newer version @develar ?

I ran into this issue and it turned out to be a http/https issue. Here’s how I resolved it (for future finders):
In my package.json:

Notice the http part — for https I expect valid certificates to play a role in success/failure.

The web server had these files:

latest.7z is a copy of my latest build produced from npm run dist

Hope this helps!
Thanks @develar !

how can i solve this issue? thanks

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Same error. My case is because of wrong time. Update windows time fix it!

I identified one possible cause my users were having…they didn’t have TLS 1.2 enabled and we force 1.2 for our HTTPS connections.

Just noting it here in case it helps someone else.

Hello everyone,

I have this problem today with this version of packages :
«electron-builder»: «22.13.1»
«electron-updater»: «4.3.9»

I have the exact same error message which is «SendRequest error», which seems to be related with the inetc plugin.

Here is the «build» part of my package.json file.

"build": {
        "publish": [
            {
                "provider": "generic",
                "url": "https://my-website.com/download"
            }
        ],
        "appId": "com.app.test",
        "win": {
            "target": "nsis-web",
            "icon": "src/images/icon.ico"
        },
        "nsisWeb": {
            "oneClick": true,
            "perMachine": false,
            "include": "build/installer.nsh",
            "deleteAppDataOnUninstall": true,
            "allowElevation": false,
            "allowToChangeInstallationDirectory": false,
            "createDesktopShortcut": true,
            "createStartMenuShortcut": true,
            "shortcutName": "My Shortcut Name",
            "runAfterFinish": true
        }
    }

My web server is an enterprise web server with HTTPS valid certificate. The CA of this certificate is a internal CA.
Do you think this can be related to the error I have today?

Is it possible to reopen this case?

Best regards.

Just wanted to add my +1 to this issue for nsis-web.
My coworkers and I have not come across this ourselves, however a large amount of our users are coming across this error. Unfortunately, most that have come across this are not tech savvy, and so it’s a little difficult for my team to track it down.

We’ve noticed that while we haven’t really heard of this for our North American users, our Brazilian users seem to be the ones who run into this most often, then followed by some other South American countries, and a handful elsewhere in the world.

We’ve tried to change from https to http, but that’s only fixed it for a few of our users, plenty still have this error.

It may be related to timeouts? If the connection takes too long to establish to the servers, INETC may be timing out. Which may be the issue for some of those regions, from our sparse ability to test out hypotheses, though it would need to be confirmed. Perhaps a longer timeout might help (possibly around 30s-1m?), as a waiting a bit for an install isn’t overly problematic.

I’m also not entirely sure if there’s a way for us to modify the timeout duration ourselves. If anyone knows how, it might help us better test out the timeout hypothesis.

Just to give you more information, I fixed the issue by using nsis target instead of nsis-web, with these settings:

{
    "build": {
        "publish": [
            {
                "provider": "generic",
                "url": "https://my-https-website.com/download",
                "channel": "latest",
                "useMultipleRangeRequest": false
            }
        ],
        "appId": "app.test.git",
        "win": {
            "target": "nsis",
            "icon": "src/images/icon.ico"
        },
        "nsis": {
            "oneClick": true,
            "perMachine": false,
            "include": "build/installer.nsh",
            "deleteAppDataOnUninstall": true,
            "allowElevation": false,
            "allowToChangeInstallationDirectory": false,
            "createDesktopShortcut": true,
            "createStartMenuShortcut": true,
            "shortcutName": "My Shortcut",
            "runAfterFinish": true
        }
    }
}

Here are my packages versions.

"electron": "15.3.0"
"electron-builder": "22.13.1"
"electron-updater": "4.3.9"

It is more link a workaround because nsis target is not downloading the .7z package file on installation. But in the case this issue is not resolved, I hope this can help some of you.

Best regards.

We’ve also opted to go with nsis instead of nsis-web. However, for differential updates, this does imply that the amount to download is doubled, whereas this wasn’t an issue for nsis-web.

We’re currently programmatically separating 32 and 64bit packaging right now to generate two separate installers of nsis as a result, as by default they’re combined for a single 32/64 installer otherwise.

A solution to this nsis-web issue would be preferable.