Need to render bundled scripts from one project into another project in MVC. Unable to use Scripts.Render since both are seperate projects. If I use <script src="relative path of bundled script"> it works but I'm not able to debug any more. Is there a solution ?
2 projects are in same solution? if so try to do file linking, then do bundle from link-files
will get you debug and production versions.
btw: any objective reason to have cross call for content files between projects?
Related
I need to test that all CSS/SCSS files in a project have been successfully minified in the build process of a .Net MVC App, or at least test that they are valid CSS.
Currently, the project is built in VSO/VSTS, and syntax errors in the CSS will not fail the build, and the app is deployed with broken CSS.
I know very little about .Net apps, I know that the main project is ProjectName.Web, the tests are ProjectName.Web.Test, and if I want to test something, I create a corresponding "-Test" class in the ".Test" project, but where would I put a test for minification of files? The files are bundled in ProjectName.Web/App_Data/BundleConfig, and use BundleTransformer to minify the files, how do I check it worked correctly after build?
Any pointers are welcome!
Here is a link to de-minify css. I would recommend you de-minify it, identify the problems, then minify it again. Usually they are small things. If you can post the deminified code then I would be happy to help.
When I create an app using composer, or install another app created using composer, there is a vendor/symfony folder included.
For example, I installed Laravel using composer. The folder vendor/symfony is present. I am not specifically referencing this in my Laravel app at all.
What is this folder, and it needed? Does the app use it, or composer use it? So if I am using an app created using Composer and dont use composer myself, can it safely be deleted and the app still run? Or could the app be using it?
Thanks
Answer is quite simple: Laravel uses Symfony components.
Check this article: http://www.sitepoint.com/build-php-framework-symfony-components/
Improved Routing Engine
Laravel 4.1 features a totally re-written routing layer. The API is
the same; however, registering routes is a full 100% faster compared
to 4.0. The entire engine has been greatly simplified, and the
dependency on Symfony Routing has been minimized to the compiling of
route expressions.
http://laravel.com/docs/master/releases
The "vendor" folder is a standard in every application / framework that uses composer to manage dependencies. In the "vendor" folder you will find all dependencies (read: libraries) that your applicatication requires.
But you will also find all libraries that your libraries require. In order to minimize code duplication, and thanks to the composer system, most open source projects now reuse parts from other open source projects.
BTW, this is great.
Symfony components are excellent and well documented, so they are currently used by many other frameworks and applications.
Inside the "vendor" you may find other libraries that you did not specifically require yourself, but as long as your correctly use composer, that's not something you should worry about.
I'm currently using the built-in BundleConfigs which work great locally and deployed, but I'd like to move all my static assets to a CDN. I know the bundle syntax allows you to specify a CDN path which will work, but does anyone have a good solution to keep the BundleConfigs in sync with your deployment scripts -- which will ultimately handle the concat/minify/copy of your statics to the CDN?
I'm currently looking into Grunt to concat/minify my styles/scrips, but this will cause me to have to manage all my bundles in my solution's BundleConfig.cs, and then again in my Gruntfile.js. Not ideal...
Thoughts or suggestions? Thanks!
If you're going to use Grunt for bundling and minification, then I don't think you need to use ASP.NET Web Optimization framework. Why to use both? Just insert links to your bundled app.css and app.js files on your page and you're all set. You can also use #if ... statements to include different versions of your files (development vs production).
Also, take a look at Gulp.js - a newer alternative to Grunt, and this project template, which already has some basic Gulp.js configuration in place: ASP.NET Solution Template
A couple of Gulp.js plugins which can help with a CDN:
gulp-s3 - Uploads your static files to Amazon S3 during a build
gulp-google-cdn - Replaces references to 3rd party libraries with Gogole CDN links
After Gulp.js is configured via gulpfile.js file, you can run:
gulp build --production
..in order to build your HTML/LESS/JS files and publish them to Amazon S3 or some other CDN.
I'm using several jars in my portlets, for instance c3p0. Now I want to avoid to put the jars in every of my portlets lib folders. How can I share one jar file within multiple portlets? And how should I integrate them in the Eclipse IDE? Add an external jar or put them in one dedicated project and include them from there?
Another solution would be to put them under ../liferay-portal-<version>/tomcat-<version>/webapps/ROOT/WEB-INF/lib
If you place them here you can add the JAR as a dependency for your portlet in the portlets liferay-plugin-package.properties (if you're using Liferay Developer Studio or Liferay IDE then there's a nice GUI for this).
Then on deployment Liferay will copy the required JARS from ROOT/WEB-INF/lib to your portlets WEB-INF/lib
This I believe is the Liferay support mechanism for doing it, and doesn't require a restart because the JARs are copied to the portlets classpath on deployment.
One way I can think off is to put all of them in the global path.
For e.g. in Tomcat you could place them at ../liferay-portal-<version>/tomcat-<version>/lib/ext and then when you configure the server-runtime library in eclipse you will have these jars in your build-path.
This link may also help you decide, but it speaks for *-service.jar but I am not sure it would work other jars in any one portlet.
I have a standard ASP.NET MVC (version 2 preview 2) solution with the actual project and server-side unit tests in separate projects.
Because this project is very client-side heavy, I want to make a ClientTest project as well that uses QUnit to test the main project.
I've thought of creating a regular ASP.NET webforms project with a single HTML file that would load the various scripts in my Scripts/ directory and test them with QUnit. Unfortunately this will spawn another ASP.NET Development Server. I could configure the port of the running MVC project server before running the tests, but there's got to be a better way that isn't just throwing the test html file into the main MVC project.
Does anyone know of a better way of going about this?
I like your idea of placing the QUnit tests in a separate project. What about using XCOPY to copy the scripts in the pre-build event?
Say your MVC project is MyProj.Web and your QUnit test project is MyProj.ClientTest (replace with your project names).
Create a Scripts folder in your ClientTest project.
From Project > MyProj.ClientTest Properties > Build Events, add the following to Pre-build event command line:
XCOPY "$(SolutionDir)MyProj.Web\Scripts" "$(ProjectDir)Scripts" /S /Y
Then in your HTML just include the appropriate JavaScript files from the Scripts folder.
Note: You will have to rebuild your ClientTest project to refresh JavaScript files when you want to rerun tests. Adjust folder names, paths and XCOPY options as needed.
Perhaps you could pick and choose techniques from this article, including using the command-line, harnessing NUnit with WatiN, and scraping test results for reporting. This solution wouldn't require a separate WebForms project to harness the tests in, since it's all handled by WatiN.
It's not too clear to me why using MVC makes a difference - if you want to integrate your tests into a CI build then gWiz's suggestion is the route to go.
If your requirement is that you want to run your tests interactively directly on the real page without affecting the look of that page then you could check out the FireUnit plugin for Firebug. You can also wrap FireUnit around QUnit as described on John Resig's blog.
If you're concerned about including test stuff then include the relevant scripts in your test/debug builds and disable/remove them in your production builds.