Team Build ignores MSBuild arguments - build

I have created a new team build definition. On every checkin, the build happens on a TFS server (another build controller). After the build completes, I want to publish the files. The MSBuild input arguments used are /p:DeployOnBuild=true;PublishProfile=QADeploy. QADeploy is the publishing profile created.
I expect the team build to succeed which happens. But the successful build does not publish or attempt to publish the files to the destination folder. Any ideas why, the publish via publish profile is not triggered?

Weird, but adding the Visual Studio Version resolved the problem:
/p:DeployOnBuild=true /p:PublishProfile=QADeploy /p:VisualStudioVersion=11.0

I had the same issue and was pulling my hair out. Check out this Similar Problem, it helped me.
I fixed it via copying both WEB and WEB APPLICATION web build targets from this path on a PC with VS installed into the matching path on the build server:
C:\Program Files\MSBuild\Microsoft\VisualStudio\v11.0
(path for VS 2012)
I am not sure if their suggestion of using the full installer for web deploy helps. I tried both suggestions at the same time and it worked there after.
Also it only works on a Web Project

Related

Windows service not showing up

I have a windows service project that I inherited and need to migrate it to a new server. I have made changes to some code, and so I created a new setup project in VS 2017. I added the .exe of the service to the set up package, and rebuilt both the service and the setup projects. When I run the .msi it seems to complete installation but when I look in the Windows Services list it's not there. What am I missing?
Any help is greatly appreciated. Thanks!
The installer probably didn't run the installutil.exe program.
You can do this manually by dropping to a command prompt then navigating to the location that the installer put the .exe file. From there run this:
installutil.exe myservice.exe
where myservice is the exe file you generated.
For more information:
https://learn.microsoft.com/en-us/dotnet/framework/tools/installutil-exe-installer-tool
Also, you might need to add the installutil.exe path. It's part of the .net framework and will be found in that install directory.

TFS 2017 - Build and Release

I am very new in TFS, need to implement CICD using TFS 2017 and its build and release feature,
when I tried to run build after creating build definition, I got error like no agent found, I googled and found how to configure agent, but I have logical confusion in my mind as below:
How Agent works with TFS 2017?
Where process of CI will be run on Agent or on TFS server?
Where I need to have msbuild ? where my built code will be placed?
What other dependencies would be there on Agent machine?
all question might be silly but as I have worked with Jenkins and Git, i dont have knowledge of Microsoft technologies, and I can't find well documents for the same.
How Agent works with TFS 2017?
In short to build with TFS, you need to Deploy an agent, in the agent machine you need to install the proper build components/SDKs accordingly based on your project.
Create a build definition. Once a build is triggered , the sources will be downloaded from the TFS repository to the agent machine and then build in the agent machine.
Related documents : Agent pools and queues; Build and Release Agents; Build definition options
Where process of CI will be run on Agent or on TFS server?
You can eanble the CI (turn on the Continuous integration trigger) in build definition. See Configure continuous integration for details. Thus the build will automatically be triggered once changes are checked in.
Related documents: A quick introduction to CI/CD ; Build and release
Where I need to have msbuild ? where my built code will be placed?
For vNext build, it's task based build system. You can define your build definition based on the tasks. See Build and release tasks .
e.g.: You can use MSBuild or Visual Studio Build task, you can specify the MSBuild Arguments as needed.
You can use the utility task: Copy and Publish Build Artifacts and Publish Build Artifacts to specify where the built code will be placed. (Artifact Type : Server/File share path)
What other dependencies would be there on Agent machine?
Refer to the answer for the first question.

Configure local build server to work with a Visual Studio Online account

Is it possible to use a local build server for a Visual Studio Online account so that with a gated check-in policy, check-ins are only committed when the build server builds successfully? I don't have expertise in this space, so ideally I'm looking for steps to do the setup.
Yes, you can do what you are asking. Simply install TFS Build Server and when you are configuring it give it the URL for your VSO Collection.

TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid but can't see MSTest.exe

I'm getting the following error on a TFS2013 build:
TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid ''.
Looking here, it would seem that the answer to this is to change the test runner from VS test runner to MSTest. However, when I try to edit the Test Run in the build definition, the test runner option is set to Visual Studio Test Runner and greyed out. What determined what is shown in this box, and how can I add MSTest?
I have installed VS2012 agents for handling tests on the server.
I fixed this by installing VS2013 on the build agent
We had the same problem as the OP but, because the TFS server is considered a production box (other departments use it for other things), we were not permitted to install VS2013 on the server. The same applied to any third party tools needed for builds, they were a pain to integrate into the build.
I eventually worked round this by using another dev box to act as a build server for TFS. By installing the Build Server component of TFS on the dev box and setting up a controller and build agents on that box, TFS could pass the responsibility for the actual build to the dev box, on which we could install anything, without compromising the TFS server itself.
While it is not perfect - an extra box and VS2013 license needed - it is by far the easiest way to avoid poluting a production TFS box. Alternatively, nominate a developer's own box and install the build agent there - the environment is ready built, it will simply slow down a little during a build.
Look at section Define Multiple Test Runs of this article. It is very informative and explains different configuration in dept. Hope this helps !!!

Has VS 2010 SP1 changed where the .config file is picked up from in VSTO add ins?

I have an outlook 2010 add-in that has a service reference to a simple web service we have set up.
The config for the service is in the app.config file.
This add-in is deployed using windows installer into the program files folder.
This has been working without a problem until yesterday.
Yesterday I installed VS 2010 SP1 and now when the add-in tries to access the web service it has the error "Could not find default endpoint element that references contract in the ServiceModel client configuration section."
Does anyone know what has changed and what is causing this problem?
If I open the project in VS, build and then run from within VS the config is picked up fine.
Thanks
Gavin
The actual solution is more simple. There was a breaking change made to VSTO 4 sp1 in that the manifest has to be a fully qualified URI. So when building your setup project, you must prefix the path to the manifest with file:/// and everything works as you'd expect again. They didn't get the documentation and tutorial pages updated in time for the release. I'm not sure that they have been yet.
Perhaps you're hitting a problem with extensionless services after installing SP1? http://support.microsoft.com/kb/2468871 - Issue 16?
I had this exact same problem. After installing Visual Studio sp1 (which installs VSTO 4 sp1), my Outlook addin could no longer find its config file for service endpoints. The only solution I've found so far is to run the VSTO setup (the new one) and choose uninstall, then run the old version that was previously installed and rebuild the setup package. If the new version is installed on the client machine, that machine will have this issue. Your setup may not detect it because typically you specify a minimum version for it to look for. I haven't found any other info about others having this problem besides yourself or anything official from MS about the problem.