I'm looking for the way to restart build agent with powershell script. If anyone knows the way in c# that's fine I can translate.
I know I can easily restart Build Service with two lines of code.
Pointing me in right direction is all I need.
I don't believe there is a way to programmatically restart the 2012 build agent. If your build agent is set to autostart you could reboot the box using PowerShell.
There isn't any way to do this via TFS API. SetBuildAgentStatus is used to set the build agent status to following: Available, Offline and Unavailable.
Related
Is there a clean way to swap an azure agent to run as a service. When I installed it I decided to install to have run manually. As time has gone on the need to convert to a service is becoming bigger and bigger. Is there an easy way to convert it over to a service without having to reinstall an agent?
Could always just tell windows to run it as a service which I imagine would work, but any other thoughts.
Thanks.
We could configure the self-hosted to run interactively or run as a service, if you have configured it run interactively, we can't change the way it works, if you want to change it, we need to remove and re-configure an agent
To remove the agent:
.\config remove
After you've removed the agent, you can configure it again.
I'm setting up a build definition in Visual Studio Team Services using a Build Agent installed on my local machine for testing.
I'm following these instructions for creating a build agent, setting up a build definition, and queuing a build. I've created the agent on my local computer and it appears in the agent pool in VSTS. The agent is enabled and ready to go. I've also created a build definition that invokes my build script. Everything up to this point appears to work fine.
At this point I'm ready to queue a build and run it. The dialog for this looks like:
The dropdown labeled "Queue" only shows the Hosted agent pool. There should be a second pool called Default but it is not appearing. I can get it to "appear" by right clicking and inspecting the HTML and then using dev tools to change the value for the Hosted option. Hosted's ID is 2, I changed it to 1 since I assumed this to be the ID for Default. Once I do this I can click "OK" and the build runs as expected -- everything is checked out on my local machine by the build agent. Presumably my assumption about the ID value is correct.
So...everything it working correctly once I muck around with the plumbing a bit. But this is definitely not the way things should be working. Why is the Default queue not showing up in the dropdown? Do I need to flip a switch somewhere to make it work? Does my account not have enough access?
Some other details:
My account is a "Pool Administrator"
The build agent is not installed as a Windows service. I start it manually from a command prompt. I've not been able to install it as a service.
The machine that has the build agent installed on it is running Windows 10 x64 Pro. It was upgraded from Windows 8 x64 Pro.
I cannot use a hosted agent as I'm building a Unity project and Unity is not supported by for hosted agents.
I know I can use Unity Cloud Build but I do not want to.
UPDATE
I've removed my previous Build Agent and installed a new one, as a service, on a Windows Azure VM running Windows 10 Enterprise x64. With this change the "Hosted" and "Default" queues are appearing as expected.
Your account needs to also have access to the agent queue. Agent pools and agent queues are different entities, and being a "pool administration" does not necessarily mean you are a "queue administrator".
In my case it helped to execute the agent configuration in a console with elevated/administrator rights. If the agent configuration is done in a console with normal rights, the agent can still be configured properly, but its queue won't appear for selection when you will be queuing a new build.
I need on clarification that I have a development server where according to the policy I shouldn't login and run the commands.
So, is there any way that I can deploy my solution using central admin just like as we did through power shell commands.
I search before, but I couldn't get the satisfactory answer?
If you're deploying new wsp, you can run Powershell command "Add-SPSolution -LiteralPath ". If it's an existing wsp, you should retract the existing wsp first before adding the updated wsp. You can check if the wsp either deployed or not in the Central Admin > System Settings > Manage Farm solution. You can also deploy the SP Solution(once added) in Central admin. After deploying it, make sure to restart the Timer Service. Here's how you can deploy the wsp using powershell.
you can setup powershell to run remotely and then use powershell commands to deploy the wsp.
Check this link on enabling powershell to run remotely Configure Remote PowerShell in SharePoint 2010
What kind of solution are you deploying? Is it a farm or sandboxed solution? You can deploy your solutiions via VS2010 without having to login to the server. Or are you referring to items that needs to be deployed via GAC?
Can we have any alternative way to make run-able the custom Workflow activity in Workflow steps.
All the time what I do is register the dll using Plugin registration tool and then restart the server. Then only we can use the custom workflow activity on Workflow.
I have tried after restarting the IIS and hoping so it'll be done but no luck.
All the time restarting server should not be any solution. Is there any alternative way for it please suggest. All you are suggestion would be greatly appreciated.
1) You do not need to restart IIS; restart the application pool (its far faster and doesn't disrupt other applications that might be running on the server; by default its the 'CrmAppPool') using the command:
%systemroot%\system32\inetsrv\appcmd recycle apppool CrmAppPool
2) Similarly, you can recycle the async process by running (powershell):
Restart-Service -displayname "Microsoft Dynamics CRM Asynchronous Processing Service"
3) Both of these commands can be run remotely using the powershell command:
powershell Invoke-Command [CrmServerName] -ScriptBlock { ["Restart-Service...."] }
4) You do not need to deploy to the server to debug plugins. Its far easier/faster to create a test harness. The link below outlines how to setup a dev environment for unit testing.
How I develop and unit test CRM 2011 plugins
CRM caches the dlls, restarting the services causes it to refresh those caches.
If you register a synchronous plugin then you need to reset IIS.
If you register an asynchronous plugin or custom workflow activity you need to reset the asynchronous service.
We don't need to restart the server to make it run the plug-in code, the only thing is you need to restart IIS after that.
Try restart IIS and then restart the asynchronous service, this must be the only thing necessary.
The point here is very specific -
It's not only true for the CRM, but is also true for any web application hosted on IIS. Web App (CRM for you case) caches dlls for the very first time when the message is executed (plugin message/event - Although this is done by .net platform internally, so to address the other similar calls more efficiently.). So, in that case you need to flush off the synced thing from your web app. And that is why you need to recycle app pool (SMART WAY -> for single application flush, and without impacting other applications on the server, you should always go for APPPOOL Recycle instead to IIS restart.)
For this, what I would suggest you is to write a powershell script to recycle AppPool for your application and trigger it on Post build event of your project (plugin project) in VS. So, that will make your process automated and will reduce your efforts to much lesser.
Regarding custom WF assembly, Since it executes under Async. Service, so you need to discard off the cached content from here as well.
Hope this helps!
You shouldn't need to restart anything.
What you need to do is increment the build number of the assembly you are updating each time you deploy it.
This makes sure that CRM knows not to use it's cached version but to load the updated one the database
If you want to see the CWAs without any need of restarts just select the activity in the plugin registration tool and press the "save" button below the properties
Just went from TFS 2008 to 2010 at a client site and now wondering what happened to the TFSBuild.proj files from the TeamBuildTypes folder. I've already got the builds and drops working and now I need to get the old deployments working again. We used to do this with AfterBuild targets in the TFSBuild.proj. That mechanism seems to have moved or disappeared in 2010.
Can anyone point me to an article or describe how the deployment options have changed in 2010?
Specifically, I need to support running psexec to install and enable Windows Services on remote deployment targets and I need to deploy some web sites / web services to remote IIS nodes as part of the automated builds.
EDIT: Just found this: http://blogs.msdn.com/jimlamb/archive/2009/11/03/upgrading-tfs-2008-build-definitions-to-tfs-2010.aspx I'm more than a little taken back by the breaking changes between 2008 and 2010. I'm gonna need advice on how to deploy remote sites and services in the new default build process template mechanism.
Check out Vishal Joshi's PDC talk on Deploying Web Applications with VS 2010 and MSDeploy. On his blog, you'll also find tips on building MSDeploy packages with MSBuild. You can run psexec from your MSBuild script or, potentially, from a customized build process template. With TFS 2010, you can use MSBuild and Windows Workflow to solve your build automation problems.
Alternatively, you can use the "Upgrade" build process template and continue using your TFSBuild.proj file. This is the default behavior for upgraded build definitions for backwards compatibility. In that case, your build is still primarily driven by MSBuild with just a thin workflow to allocate an agent and run MSBuild.
Another option is to use TFS 2010 Build Agent on the server that you deploy to. This is how Visual Studio Lab Management deploys.
I have written a blog post about this: Continuous deployment with TFS 2010 Build Agent