I am trying to implement a nightly build environment for our SharePoint solution that includes VS 2008 and VS 2008 extensions for Windows SharePoint Services 3.0 (version 1.2).
When I deploy via the VS 2008 GUI it works fine.
When I use the command line:
c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe SharePoint.sln /Deploy Release
I get the following error:
------ Deploy started: Project: SharePoint.Site, Configuration: Release Any CPU ------
------ Generate solution file and setup batch file ------
Creating solution ...
System.NotImplementedException
Error: The method or operation is not implemented.
Others seem to be having similar issues.
VSeWSS 1.2 doesn't support command line builds. I would either try the CTP for VSeWSS 1.3 or a community tool like STSDev or WSPBuilder.
Related
I am trying to do a Visual Studio Build on TFS 2017. So far, it seems to do the build, but will not do the standard Publish/Deploy I am used to on my local file system, with the Precompiled WCF app, etc. This is what I have so far attached as images, and the PublishProfile I have switched to in desperation. They have VS 2017 installed on the build server, and have updated the MS Build to the latest version. Please help! :)
Visual Studio Build
VM Deploy XML
Check the build log to see whether the deployment executed.
Run the MSBuild command locally on the build agent machine to see whether it works.
Try the following arguments:
/p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\" /p:DeployDefaultTarget=WebPublish
I created a project using Visual Studio 2010 and trying to create the build in TFS 2013. I am getting the following error. Target Framework is 4.0. Why my build server is looking for Visual Studio 12.0 folder? How to change this settings? I appreciate any suggestions.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" was not found
Copy the directory "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0" from development machine to the build machine.
http://howtoscript.blogspot.com.tr/2014/05/error-msb4019-imported-project-cprogram.html?view=magazine
You need to do one of the following:
Change the build configuration to use 2010
Install VS 2013 on the build server.
I would recommend upgrading your visual studio anyway as you are already 2 versions behind with CTP's already available for DEV14,..
I've recently upgraded to Visual Studio 2013, which has caused back to back problems when building externally using MSBuild (API or Executable with command line args)
Issue #1
When building with MSBuild it doesn't generate Fake assemblies which are required for our Unit Tests, this leads to build failures. A simple build in visual studio fixes this temporarily, until a new fake assembly needs to be generated.
Issue #2
When running code analysis this complains with the following:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(284,5):
error MSB4127: The "CodeAnalysis" task could not be instantiated from the assembly "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\.\FxCopTask.dll".
Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.CodeAnalysis' to type 'Microsoft.Build.Framework.ITask'.
I only have Visual Studio 2013 installed on my machine, apparently installing an older version could fix the issue, but it's not something which I can do. (VS 2013 Ships with its own MSBuild 12.0 which is located in a different directory to the previous MSBuild).
I'm unsure why Visual Studio is behaving any differently to MSBuild, i'm simply pointing to the solution file like so...
msbuild.exe "path\solution.sln" /property:Configuration=Debug
So, Visual Studio 2013 comes with a new version of MSBuild i.e. MSBuild 12.0. Once installed, it changes the path so that the new version is used by default.
Looks like your solution compiles with visual studio 2012, you can either specify the full path to msbuild.exe such as
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild "path\solution.sln" /property:Configuration=Debug
or set the visual studio 2012 environment variables by running the following before executing msbuild
"%VS110COMNTOOLS%"\vsvars32.bat // VS2012 environment variables
EDIT: Using MSbuild 12.0 assemblies "C:\Program Files (x86)\MSBuild\12.0\Bin\" fixes the issue with the code Analysis bug.
We were building a Visual Studio 2010 solution with the following msbuild command:
msbuild MySolution.sln /p:DeployOnBuild=true;DeployTarget=Package
This command built the solution and created the deployment packages for web projects in the solution.
But after we've migrated to Visual Studio 2012 this command doesn't work anymore. The solution is built, but no deployment packages are created.
How to fix it?
The problem was exactly the same as in this question.
Copying *C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web** from a local machine to a remote CI server.
I use this manually, should be a matching msbuild parameter
Using the Publish Web Wizard to Create a Deployment Package
My configuration:
VS2010 solution
TFS 2008
Build server - TFS 2008
Build server also has VS2008 Team Suite and VS2010 ultimate installed
TFS 2008 builds my VS2010 solution properly. But when it comes time to run the unit tests I get the following MsTest error.
Using "TestToolsTask" task from
assembly "D:\Program Files\Microsoft
Visual Studio
9.0\Common7\IDE\PrivateAssemblies\Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll".
Task "TestToolsTask" Command:
d:\Program Files\Microsoft Visual
Studio 10.0\Common7\IDE\MSTest.exe
/nologo
/searchpathroot:"D:\Builds\App\Source\86\Binaries"
/resultsfileroot:"D:\Builds\App\Source\86\TestResults"
/testcontainer:"D:\Builds\App\Source\86\Binaries\\Tests.dll"
/publish:"http://tfsServer:8080/"
/publishbuild:"vstfs:///Build/Build/26029"
/teamproject:"Proposal" The
"TestToolsTask" task is using
"MSTest.exe" from "d:\Program
Files\Microsoft Visual Studio
10.0\Common7\IDE\MSTest.exe". No platform specified for publish
operation. For switch syntax, type
"MSTest /help"
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1.
[D:\Builds\App\Source\86\BuildType\TFSBuild.proj]
The previous error was converted to a
warning because the task was called
with ContinueOnError=true. Build
continuing because "ContinueOnError"
on the task "TestToolsTask" is set to
"true". Done executing task
"TestToolsTask" -- FAILED.
I am not sure what is causing MsTest to fail.
Things tried:
- Provided write access to the build folder to the service account that builds the source on the build machine
You can execute a VS2010 build from within TFS2008's MSBuild, but it looks as if it's using Visual Studio 9.0 TestToolsTask (2008) to try to run a Visual Studio 10.0 (2010) test project (MSTest.exe). I'd try tweaking MSBuild to run the TestToolsTask from the "Microsoft Visual Studio 10.0" folder rather than "9.0", so that the entire process is using the same version of the tools. You can override the tools paths in your tfsbuild.proj file's Properties to ensure the correct version of Visual Studio is used to build with - something similar may apply to the test tools.
Alternatively, it's running the VS2010 test tools correctly, but still trying to use a command line that is specific to 2008 - check the settings and see if you can tweak the command line (you may need to override the MS targets files that is running the build if it's a 2008 version). For example in TFS 2010, a lot of command lines changed from using a simple "server:MyServer" to something like "collection:http://MyServer:8080/tfs/MyCollection". You may therefore have to alter the command line to gain full compatibility with the 2010 version of the tool that is now running, even if it still ultimately points at a 2008 server.
My third suggestion (which isn't necessarily very helpful) is to just upgrade to TFS2010 - it's typically a painless install, vastly better than 2008, and will eliminate any difficulties caused by using a hybrid 2008/2010 setup. (If it helps, I was reluctant to upgrade to 2010 because the 2005->2008 upgrade was 8 days of sheer hell. But in comparison the core of the upgrade to 2010 only took a few hours and "just worked" - the install/upgrade process is much improved)
Jason had the correct idea that lead me down to the correct solution.
In my case, I had to update the "Microsoft.TeamFoundation.Build.targets" to point to "Microsoft.TeamFoundation.Build.ProcessComponents.dll" (VS2010 dll) instead of "Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll" (VS2008 dll)
I also had to make sure that the PlatformToBuild was specified in the TfsBuild.proj file.
Once these 2 steps were done, UnitTests were being run as part of the CI build using TFS2008 and a VS2010 solution.
I have blogged about the solution in detail here: http://blog.aggregatedintelligence.com/2011/03/vs2010-tfs-2008-and-unit-tests.html