Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployment on Azure. #11

Closed
JimBobSquarePants opened this issue Mar 4, 2015 · 7 comments
Closed

Deployment on Azure. #11

JimBobSquarePants opened this issue Mar 4, 2015 · 7 comments

Comments

@JimBobSquarePants
Copy link

Would it be possible for JavaScript Engine Switcher for .Net: V8 to wrap a release build of ClearScript so that the extra C++ binaries would not be required?

This would make it much easier to deploy on Azure as well as other servers.
https://msdn.microsoft.com/en-us/library/azure/hh694038.aspx?f=255&MSPPError=-2147217396

At present I am having to use JavaScript Engine Switcher for .Net: Jint in my project Cruncher due to the difficulties in deployment which is non optimal as Jint takes an extraordinarily long time to initialise and parser on first run.

@Daniel15
Copy link

Daniel15 commented Mar 7, 2015

What's wrong with extra C++ binaries? The link you posted seems to say that it's fine as long as you deploy the .dll files correctly. Could you use the MSIE engine in Azure instead? The Azure VMs may support that natively.

@Taritsyn
Copy link
Owner

Taritsyn commented Mar 7, 2015

Would it be possible for JavaScript Engine Switcher for .Net: V8 to wrap a release build of ClearScript so that the extra C++ binaries would not be required?

What's stopping you to add the msvcp110.dll and msvcr110.dll assemblies in your application package? I think it is unnecessary to add the standard assemblies in the heavy JavaScriptEngineSwitcher.V8 package.

At present I am having to use JavaScript Engine Switcher for .Net: Jint in my project Cruncher due to the difficulties in deployment which is non optimal as Jint takes an extraordinarily long time to initialise and parser on first run.

Jint and Jurassic originally are slow JS engines, because it are written on managed code.

... in my project Cruncher ...

In CoffeeScript and Autoprefixer functionality I saw a lot of familiar code from the Bundle Transformer :-)

In general, tools such as the Bundle Transformer, Cassette and SquishIt are gradually fading. Now need switch to Grunt or Gulp. In “Additional reading and resources” section of the Bundle Transformer documentation, there is information on theme of switching to Grunt/Gulp.

@Daniel15
Copy link

Daniel15 commented Mar 7, 2015

In general, tools such as the Bundle Transformer, Cassette and SquishIt are gradually fading. Now need switch to Grunt or Gulp.

Also the ASP.NET 5 beta does not include ASP.NET Web Optimization Framework (System.Web.Optimization) at all, instead it uses Grunt. I'd recommend Webpack for bundling JavaScript :)

@Daniel15
Copy link

Daniel15 commented Mar 7, 2015

Having said that I think there's still value in .NET tools for combination/minification, in scenarios where you don't want to use Node.js tools like Grunt/Gulp/Webpack.

@Taritsyn
Copy link
Owner

Taritsyn commented Mar 7, 2015

I just voiced recommendations of Microsoft.

@JimBobSquarePants
Copy link
Author

Well... It is some fantastically clever code! 😄

I made a point of saying where I found it in the source also of course...

@Daniel15 As I recall the MSIE engine didn't work on Azure, I'll check again though.
@Taritsyn, I'm actually surprised that Microsoft have gone that direction, Node is a nightmare on Windows machines and adding another dependency can be a hassle.

I'll probably just add the files in my solution. Thanks.

@Taritsyn
Copy link
Owner

@JimBobSquarePants In any case, you will need to add a additional C++ libraries for the libsass-net.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants