Other common solutions to the problem are the .NET version.
But if that still doesn't work, it could be the content type on your files. This often happens when you have folders in your project (like App_Code) and add new items to those folders. Right click on those files in your solution explorer and select Properties.. --> change their type from "Content" to "Compile" and your reference should succeed:
Fiction: If a book is still under copyright, scanning it without permission is illegal.
Fact: This is probably the most common misconception about Google Books, and about copyright law in general. The "fair use" provisions of U.S. copyright law (USC 17 107) describe the conditions under which someone may copy a work without the copyright holder's permission, like recording a TV show to watch later or quoting from an article in a blog post. Fair use is designed to safeguard copying that doesn't harm people's incentive or ability to produce and sell creative work, including books.
We've carefully designed Google Books to make sure our use of books is fair and fully consistent with the law. Copyright law is aimed at protecting and enhancing the value of creative works in order to encourage more of them–in this case, to ensure that authors write and publishers publish. We believe that by creating new opportunities for readers to find and buy books, we can help authors and publishers sell more of them. You can read more about fair use here.
Given the obvious risk of being able to reconstitute the book samples into the whole the established publishing regime must have disapproved. Google engineers must have seen that coming and had some reasonable arguments to defend the position. To be a fly on the wall there...
David Heinemeier Hansson has a great article on his blog titled TDD is Dead Long Live Testing. I wrote a similar article here in 2012: To Unit Test or not to Unit Test. TDD is a great programming technique and I cannot agree more with David that when it works, it brings a new confidence to the iterative development practice that is hard to match. But set in its proper context of the software and testing life cycle, TDD is an interesting technique that has costs often exceeding its benefits.
The point of this post is simple -- software training cannot be successful until users have the live system in front of them with a goal in mind they want the software to help achieve.
I am not an expert when it comes to the fine details of software training. How best to conduct the sessions and how to present the content are things I respect but have little practical expertise in. I am, however, a witness to a great many people who learn how to use new software systems and I am (painfully) aware of the kinds of problems they have.
I am not naive about the difficulty of setting up the "software in front of your users with goal in mind" scenario but in most software deployments there is one convenient moment that puts your users in a position to succeed -- during parallel testing. A parallel test is no small task but it is the perfect opportunity for this scenario to exist for a wide range of users. Piggy backing on the parallel test for training is superior in efficiency of dollar spent per unit of user skill gained to traditional up-front user training because of the psychological engagement only real use cases can invoke. I strongly recommend parallel testing for any system roll-out for many other good reasons but utilizing the optimal training moment is one of the best side effects.
Psychologically, when users have "skin in the game" they can learn. And to be painfully realistic, very few are capable of learning before that point. We are busy, we have deadlines looming, we simply cannot pay attention to a system training for a system we will not touch for another 2 weeks and we've never seen before!
So I am recommending the abolishment of traditional up-front user training sessions? No. What I am recommending is a shifting of the goal of that up front meeting (and hopefully reducing its duration and expectations). It can provide enough of a primer that the users think the system will be easy to use. Show high level things it can do. Describe in glorious detail how it will make their life easier. Set up scenarios and make the software sing. Its almost a full sales demo, but with the system's future users instead of its purchasers. Get them excited about it. That first training session is more about "buy-in" and emotional connection to the new reality. Make them want it by selling the system. That is about as good as you can hope for. This is a huge difference from the usual top-down approach that has a tendency to demoralize future users and encourage animosity towards support staff (notice how support teams are seperated from the trainers? Why are these are different teams? Support is very often "just in time" training!) negative feedback that finds its way back to the stakeholders as complaints about the "complexity of the system". That rationally stubborn user behaviour can be curbed by acknowledging the very human need for buy in in a sales-like kick off meeting. Of course there are limits to the success of this initiative and after that buy in meeting there may still be resistors, but at least you've identified them (or perhaps the solution doesnt solve their problems and thats a whole 'nother issue :)).
TL;DR: Up front training is not successful for logical reasons. Use up front sessions to create user buy-in instead of training. Parallel testing is often the ideal time to train users.
WebApplication.deploy.cmd -- when I run this command on my local machine I was getting this message:
To deploy this Web package, Web Deploy (msdeploy.exe) must be installed on the computer that runs the .cmd file. For information about how to install Web Deploy, see the following URL:
To install V2 of the MSDEPLOY.exe you MUST FIRST UNINSTALL V1! There is no failure message if you install V2 after V1, it just simply doesnt write the V2 files to the V2 directory if V1 is installed. Odd behaviour, but is what it is.