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.
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.
Problem:
I have been trying to integrate minification of javascript and css files in our VS2010 (.net 4.) projects. From what I hear, .net 4.5 and VS2012 will have minification build into the editor, so it will be as easy as setting a flag it will work. Unfortunately we are sill on VS2010 (.net 4.0).
Let me explain what I want to do and what I dont want to do.
I dont want to do big setups with classes/config file(s)/etc just to minify because all that stuff will have to be loaded on our build machine and even the build xml files might have to be modifies to make it work. Also, once we go to vs2012 and .net 4.5 all these configs/classes/etc will have to be discarded because vs2012 will have the build in functionality.
Here is what I think might be the best option. Since I am using the ScriptManager and it can already pull either a .debug.js (non-minified) or a .js (minified) script based on the build type, it seems all i need to do is to have some sort of (pre?) build event that will re-build a non-minified .js file into a minified one. Obviously the build event will have to call a minication module which would have to be installed on local computer (the YUI Compressor seems very nice). The module would update the minified .js file.
I have been reading about this, but I am getting a little bit lost. There are a lot of third party tools with bunch of setup and classes which I do not want to add.
Did anyone do something similar as I explained about?
If not what is the next best simple solution?
(By the way, if you are going to say move to VS2012/4.5, thats not a solution for us at this point)
Solution:
Thank you Parv Sharma for your answer.
I would just like to explain what I did so that it may help someone in the future.
I installed the Microsoft Ajax Minifier
Created a batch file to add minifer to ENVIRONMENT PATH variables: setx path /m "%PATH%;C:\Program Files\Microsoft\Microsoft Ajax Minifier"
Added the following pre-build events into my project:
ajaxmin $(ProjectDir)Script.js -out $(ProjectDir)Script.min.js -clobber
If Script.min.js does not exist, it will be created by the build event, but it will not be added to the project (not sure how to do that through the events).
When you add a new script file, mynewscript.js, just create a second blank file called mynewscript.min.js and add an pre-build event for it.
Using this approach the only thing you have to do to the build machine is run the Microsoft Ajax Minifier setup package and the batch file. Thats it everything else will be part of your pre-build events.
what you are looking for is probably this
http://ajaxmin.codeplex.com/documentation
by using this you would be able to use this third party tool as the minifier
after downloading the tool you have 2 options
1. edit the MSBUILD file to include building the js as per build event
OR 2. to attach this tool to VS and assign a key compbination to it.. this way you would be able to minify whenever you want just like we do F5 OR Cntrl-Shift-B
Attaching to VS is easy just to to external tools and in the Tools menu and add this tool with the required params
I am working to setup a build server using Team City to build and deploy asp.net web applications to a staging site with transformed web.configs automatically. Everything is working except that the code that ends up on the website (the aspx files) have the HTML in them when you open them in notepad.
Before all of this I was using web deployment projects with websites, and the code was compiled. If you opened one after it was deployed, it said it was a marker file.
I have tried some tutorials on how this process should work, but the code always ends up in an editable state (the html).
My question is:
What do I need to do to get MSBUILD from the command line to ultimately have precompiled code on the webs server?
Any suggestions, links, pointers, or ideas would be very helpful to me.
You need to invoke the aspnet_compiler tool to do this. There are some limitations or complications depending on exactly what you need to do for things like strong-naming. The MSDN article here has pointers.
I used to have MSBuild project steps that did this, but we decided to drop precompiling because our clients want to integrate our product into their internal portals, and precompiling made things complicated for them.
Are you using MS Web Deploy? I use it regularly for automated deployments from my Team City Build server to dev, staging, QA, etc. And I'm transforming configurations as well.
If you want to check out this alternative you can follow the excellent guide by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
Working on an intranet where we have about 20 different web apps - some .net, some classic asp.
Currently each .net app is its own solution. There are advantages to this - we can build & deploy just one app, without affecting other apps, and all the apps share a session - but we can't use master pages, and there are real challenges using localization resources, shared css and js, etc. Build & deployment is done completely manually, which is a real problem.
I'm trying to set up a structure that will allow us to take advantage of VS2008 features, but still have the ability to update one app without affecting the others while still using features like master pages and localization resources, and sharing session between apps (so we can't set up virtual directories for each app).
If I set up single solution that looks like:
/Root
- App_GlobalResources/
- shared
-- masterpages/
-- css/
- App1/
- App2/
...
- AppN/
..
- ClassicASP1/
then the problem is that the build just produces a single DLL (Root.dll) - this will simply not scale to 20+ apps, all of which have different development cycles.
Is it possible (using nant, or some other build tool) to build multiple DLLs? In this case, I'd like to end up with Root.dll (contains the global resources at least) and App1.dll and App2.dll.
Any other suggestions or references I should look at?
I'm not sure you can do what you want to do, sadly. VS tends to make one DLL per unique project (not solution), and it appears you have just one project, so hence, one DLL.
I'd suggest you keep one project (csproj) per application, but use NANT to build them all (ie, one at a time, together, in order), and package them all up for deployment. That way you can do a single point deployment, but still keep the apps seperate.
I'm surprised you can't use master pages in the sub-folders. You'd need to replicate them for each AppN folder, but again - NANT could be used to pull those in from a common place when you build your deployment package.
Writing a build and deployment script takes a while to get right, but I've found that once it's done, it pays for itself very quickly - even if the only payment is your sanity!
There is a solution to this problem. In short, it entails creating a Web Site Project (which can have the masterpage and whatnot) and several subdirectories, each containing a web project. In the main web project you exclude the subdirs from the project. You then add the project files to the solution. This (updated) link tells you all about it.
-Edoode
I would advise using MSBuild instead of Nant. It is more native to visual studio.