asar is a PiTA to install in Windows (7 64 bit here) about asar HOT 12 CLOSED

Note: the last time I ran into a similar message from npm I ended-up installing a Net Framework which promptly broke all the other Net Frameworks so it anyone has a link - that'd be great ;0

from asar.

ASAR isn't written in C# at all - why are you getting prompted to install the .NET Framework?

from asar.

What I get (it's not easy to copy this from terminal) is....

C:\Users\john>npm install asar
\

[email protected] install C:\Users\john\node_modules\asar\node_modules\chromiu
m-pickle\node_modules\native-mate
echo

ECHO is on.

[email protected] install C:\Users\john\node_modules\asar\node_modules\chr
omium-pickle
node-gyp rebuild

C:\Users\john\node_modules\asar\node_modules\chromium-pickle>node "E:\nodejs\nod
e_modules\npm\bin\node-gyp-bin....\node_modules\node-gyp\bin\node-gyp.js" reb
uild
Warning: Missing input files:
C:\Users\john\node_modules\asar\node_modules\chromium-pickle\node_modules\native
-mate\tests\compilation.cc
Building the projects in this solution one at a time. To enable parallel build,
please add the "/m" switch.
MSBUILD : error MSB3428: Could not load the Visual C++ component "VCBuild.exe".
To fix this, 1) install the .NET Framework 2.0 SDK, 2) install Microsoft Visua
l Studio 2005 or 3) add the location of the component to the system path if it
is installed elsewhere. [C:\Users\john\node_modules\asar\node_modules\chromium
-pickle\build\binding.sln]
MSBUILD : error MSB3428: Could not load the Visual C++ component "VCBuild.exe".
To fix this, 1) install the .NET Framework 2.0 SDK, 2) install Microsoft Visua
l Studio 2005 or 3) add the location of the component to the system path if it
is installed elsewhere. [C:\Users\john\node_modules\asar\node_modules\chromium
-pickle\build\binding.sln]
gyp ERR! build error
gyp ERR! stack Error: C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe failed with exit code: 1
gyp ERR! stack at ChildProcess.onExit (E:\nodejs\node_modules\npm\node_modul
es\node-gyp\lib\build.js:267:23)
gyp ERR! stack at ChildProcess.emit (events.js:98:17)
gyp ERR! stack at Process.ChildProcess._handle.onexit (child_process.js:820:
12)
gyp ERR! System Windows_NT 6.1.7601
gyp ERR! command "node" "E:\nodejs\node_modules\npm\node_modules\node-gyp
bin\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\john\node_modules\asar\node_modules\chromium-pickle
gyp ERR! node -v v0.10.35
gyp ERR! node-gyp -v v1.0.1
gyp ERR! not ok

npm ERR! [email protected] install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is most likely a problem with the chromium-pickle package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-gyp rebuild
npm ERR! You can get their info via:
npm ERR! npm owner ls chromium-pickle
npm ERR! There is likely additional logging output above.
npm ERR! System Windows_NT 6.1.7601
npm ERR! command "E:\nodejs\node.exe" "E:\nodejs\node_modules\npm\bin\n
pm-cli.js" "install" "asar"
npm ERR! cwd C:\Users\john
npm ERR! node -v v0.10.35
npm ERR! npm -v 1.4.28
npm ERR! code ELIFECYCLE
npm ERR! not ok code 0

On 24 February 2015 at 01:45, Paul Betts [email protected] wrote:
ASAR isn't written in C# at all - why are you getting prompted to install the .NET Framework?

—
Reply to this email directly or view it on GitHub.

from asar.

You just need a visual studio compiler for the native dependency chromium-pickle.
Try installing MS Visual Studio Express 2013 for Windows Desktop. (That works for me.)

Edit: Tip: when pasting console output, you can surround it with 3 backticks ``` to prevent it from being interpreted as markdown.

from asar.

Actually Visual Studio 2013 Community Edition would be better, but @bwin's advice generally still stands. Agree that this is a super misleading error message though

from asar.

So to package my HTML5/CSS application I need Node, NPM, Python and MS Visual Studio installed - that's silly...

Time for a trip back to the drawing board on that one - particularly as I'm guessing the issues relate to handling/serialising binary content which - erm - why would you be packaging/distributing binary content for an HTML5/CSS/JS application??

from asar.

@shrewdlogarithm Sorry to hear it's not working for you. You're certainly free to try another solution like CEF!

from asar.

why would you be packaging/distributing binary content for an HTML5/CSS/JS application??

images, fonts... edit: sorry missed it: also native modules of course

I personally dislike the dependency on a native module, but you make it sound worse than it is. It just needs the default windows native build-toolchain (which happens to be ms visual studio). You need that for every native module.
Edit: In other words: it needs a c++ compiler.

from asar.

Images/Fonts - fair enough tho I never ship binary Fonts because that's a
security issue, BASE64 encoding in the stylesheet is a better solution (esp
if you strip the font down to just the glyphs you're using - memory
saved!!) - I even BASE64 encode images sometimes because it's neater (and
MUCH harder for people to steal!!) :)

The same security concerns make me wary of native Node Modules - I realise
they're sometimes necessary but I wouldn't include one unless I HAD to (esp
as Node has built-in gzip support and non-native tar support?)

You're missing the issue that people like myself - looking at deploying web
apps with atom-shell - are NOT native developers (I've been clean since
98!) . I've no use for VS, I happened to have Python 3.4 from a project I
did last year but that didn't help me as this needs 2.7< and
installing/understand those just to package an app is a bit of an ask (and
leads to potential support issues down-the-line surely?)

On 24 February 2015 at 03:11, Benjamin Winkler [email protected]
wrote:

why would you be packaging/distributing binary content for an HTML5/CSS/JS
application??
images, fonts...

I personally dislike the dependency on a native module, but you make it
sound worse than it is. It just needs the default windows native
build-toolchain (which happens to be ms visual studio). You need that for
every native module.

—
Reply to this email directly or view it on GitHub
#20 (comment).

from asar.

Yeah, you're right. It could/should be simplified for the web (only) developers. Getting node+npm up and running should be enough to get started.
I'll make a PR in the next days. But zcbenz has to decide on this.

from asar.

I appreciate what's being attemped with asar - I'm not entirely sure why
the same couldn't be done with uncompressed zip or tar but that's not my
field so I'll assume there are good reasons for making a new wheel!

It's arguably a lot more elegant than unzipping files into temp EVERY time
you run and I realise the tools will develop - I just wanted to raise the
Windows build issue - and the general "distribution is a bit of a pain"
issue in the other thread too.

Would one option not be building zip/tar->asar support within atom-shell's
executable (command line option to convert the app -> asar) or a separate
asar executable build/gz/zip/tar converter?

and as an aside - I assume atom-shell locks the asar whilst running, so an
auto-update mechanism would have to kill the current atom-shell, replace
the asar and then re-run atom??

On 24 February 2015 at 03:38, Benjamin Winkler [email protected]
wrote:

Yeah, you're right. It could/should be simplified for the web (only)
developers. Getting node+npm up and running should be enough to get started.
I'll make a PR in the next days. But zcbenz has to decide on this.

—
Reply to this email directly or view it on GitHub
#20 (comment).

from asar.

Following this up, I decided to try to convert my node-webkit GitHub auto-updater to work for atom/asar projects too

To avoid having to install VS I switched to a Linux MINT virtualmachineI and I ran into that stupid Debian 'node' collision issue which meant it took EONS to get asar built (but it does seem to work once you kick and punch it into submission)

Not wanting to continue the battle against Debian's ass-backwards approach to module renaming, I switched back to Windows, installed VS and asar builds and installs there AOK - finally.

Having built and tested my app there, I deployed it to RedHat OpenShift and it crashed-and-burned - because it doesn't support/have access to the "gyp" module (and there's a 6+month old support ticket so it's not going to be fixed anytime soon)

This is the real downside to relying to native modules - you make your software hard to deploy pretty-much everywhere!?

I really do think a slicker solution to "pickling" may be required...

from asar.