This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, thanks for this wonderful plugin! As a hobby ruby-on-rails programmer I'm very fond of finally being able to use Sass in my day-to-day job working with ASP.NET projects! What is the best practice for including the Mindscape.WebWorkbench.Framework.dll in my project? Do I need other dlls? Why am I asking? I can not assume that other developers in my team use the same extension for Visual Studio (VS). Nor does my NAnt build script know of VS Extensions. Will NAnt even know that it needs to parse scss files into css files? Cheers, Patrick
|
|
|
Hello Patrick, Web Workbench compiles SCSS files to CSS and CoffeeScript files to JavaScript, and the resulting CSS and JavaScript files become part of your project. You should include the .css and .js files in source control (source control plugins like TFS and AnkhSVN will do this for you), so there is no need to recompile the SCSS or CoffeeScript files as part of your automated build. You shouldn't include the Web Workbench DLL as part of your project -- the Web Workbench DLL runs only as a Visual Studio add-in, and must be installed through the extension (VSIX file). That said, you may still want to run the Sass compiler as part of your automated build if the other developers on your team are going to be editing the SCSS files and are not using Web Workbench (so they will be committing only the SCSS file, not the generated CSS). In this case you will need to invoke the Sass Ruby compiler (i.e. install Ruby and the Sass gem on the build server, and run the sass command from your NAnt script). You can't really hook into Web Workbench for this but all we're doing is calling the Sass compiler anyway, so it will have the same result. Hope that makes sense -- let us know if you need any further info. |
|
|
It would be nice if the Web Workbench included an out-of-the-box solution for this. I'm using MSBuild and I also wish this were easier. I think this affects users editing SCSS even if they have the Web Workbench installed. Web Workbench causes a SCSS file to recompile when it is saved in Visual Studio. However, SCSS files can @import other SCSS or CSS files. If a change is made to a "base" SCSS file, the base file will recompile on the spot. Files that @import the base file will not recompile unless somebody opens them in Visual Studio and re-saves them. Having support SCSS compilation as part of a build process would mitigate this issue, as we could then direct the build process to recompile all of the SCSS files for each build. So long as somebody does a build before a commit, they should be covered. If this just took the form of a command-line executable, that would be great. I'll be installing sass on the build server for the time being. However, it seems like a bad idea to have Web Workbench do compilation for development and something else do compilation for production. At the moment, Web Workbench may just be calling the sass compiler, but who knows if that will change in the future? What if some options or a control panel get added to Web Workbench? What about keeping versions in sync? I'd prefer to keep the development environment as similiar to the production environment as possible. Just my two cents. Keep up the good work! |
|
|
Thanks for the feedback! You're right that doing different things in development and production is a recipe for trouble, and that it's probably unavoidable until we either sort out dependency detection or provide something that runs at build time. This is definitely on our radar so it's mainly a matter of finding the time -- and feedback likes this definitely helps us prioritise! |
|