I've configured Release Management to pick up when source is checked in and deploy the code. However, I am having a problem:
System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Exception: Package location "\devserver1\Drop\Release Manager Build (Continuous)\Release Manager Build (Continuous)_20140115.15_PublishedWebsites\FrontEnd_Package" does not exists or Application Pool user does not have access. at Microsoft.TeamFoundation.Release.Common.Helpers.FileTransferer.CopyFolder(String sourceFolder, String destFolder) at Microsoft.TeamFoundation.Release.Services.DeploymentControllerService.GetPackageFileInfos(String packageLocation) --- End of inner exception stack trace ---
The strange thing is that if I simply open up Release Management tool, go to the failed deployment and click "retry deployment" it works first time no problem.
I have tried giving "Everyone", "TFSService" & "ReleaseManagement" users full permissions to both the drop folder and the build folder but still it doesn't work.
Please help!
So turns out that because I didn't have a "Configuration" set up in my build process, nothing was created as there was no default either. Once I created this it seemed to work.
My discussion with Microsoft here:
MSDN:Release Management - Continuous Integration
I had to give "Network Service" explicit permission to the drop folder.
Related
(26.07.2016)I am using TFS2015 Update3 in a VM.
When I try to queue a build through the web interface or from Team Explorer, I get the following.
Then I restart all services related to TFS in services.msc and then after some time it starts working again.
So this happens too often.
I have a custom pool running:
Is there a way to debug this behaviour?
Examining the Log files
Link to Worker log file
Link to Agent log file
Exception occurs in this order here:
Checking if artifacts directory exists C:\workspaces\agent\_work\2\a
Deleting artifacts directory
System.ComponentModel.Win32Exception (0x80004005): The directory is not empty
at Microsoft.TeamFoundation.Common.FileSpec.DeleteDirectoryLongPath(String path, Boolean recursive, Boolean followJunctionPoints)
The weird thing is, queueing new build works most of the time, this happens only sporadically
It could be, that I have opened a file from that folder in notepad with many tabs open. Will observe if this issue persists and report.
If this is happening sporadically, it might a long path exists here in artifacts:
C:\workspaces\agent_work\2\a
Or, there was a cancelled build which left the artifact directory half cleaned which exposed a bug in cleaning.
The 2.x agent isn't subject to long paths (net core) but only works with 2017+:
https://github.com/Microsoft/vsts-agent
We can troubleshoot but it would be good to get to 2017+ (2018 QU3 is out) with a 2.x agent.
If that's not an option, message me and we can dig into what I think is a cancel / state bug.
I am trying to run HermesJMS from soapUI 5.2.1 on Windows7 x64
The preferences and path to hermes config are set correctly.
The problem is that I cannot write to C: drive. So I had to install SOAPUI and Hermes in alternative places. I have changed hermes_home, java_home and hermes_config to my actual paths. Paths do not contain whitespaces etc. When I run hermes.bat from command prompt, it starts correctly.
However, when I try SoapUI -> Project -> right click -> start HermesJMS - nothing happens. Things are as bad that I even couldn't find anything useful neither in soapui nor in hermes logs.
File structure is as follows:
hermes_home = ...\SoapUI-5.2.1\hermesJMS
hermes_config = ...\SoapUI-5.2.1\hermesJMS\cfg
Does anyone have an idea what could be going on? Or for a start where can i find stdout and stderr of a script which starts hermes from SoapUI?
Here are the steps to configure SoapUI with HermesJMS:
Preferences: In SoapUI tool, go to File -> Preferences -> Tools and set the path for HermesJMS, which is mentioned here in the documentation. Then, save the preferences.
Start HermesJMS: Now, select your soapui project. Right click -> Start HermesJMS. At this point, a dialog will be shown requesting user to choose for the hermes configuration directory where it looks for the file called hermes-config.xml. Default location it looks for is under {user.home}\.hermes.
You already mentioned hermesJMS is already configured to connect with TIBCO EMS, so you will be having that file on your system.
Configuring JMS: I believe this may not really applicable for you. But, in case if someone is needed, here are the detailed steps provided, citing the documentation.
-- Here for activemq from the official site.
-- Here for TIBCO EMS. And here, there. Also find some information relevant to EMS connection issues here.
Permissions Issue on C Drive:
There is no constraint from SmartBear that SoapUI needs to be installed in a specific drive on the computer. So, you are free to install the software on your machine where you have the rights to do so.
Does anyone have an idea what could be going on? Or for a start where can i find stdout and stderr of a script which starts hermes from SoapUI?
Best thing you could do is to go the logs to find what is going on. You can find lot of useful information from the logs when the situation requires. SoapUI logs can be found under {user.home} when you invoked it from windows -> start menu. If you start SoapUI from command line (go to SOAPUI_HOME\bin) using soapui.bat script, then you should be able so the log on the console itself also log files can be found in the same directory where you invoked.
This time the above instruction should resolve your issue.
I'm trying to setup Standard Lab Environment with TFS 2012 utilizing Build-Deploy-Test workflow. I setup test controller and test agents but when the LabManagement workflow starts executing I get an exception on RunDeploymentTask activity
Initial Property Values
BuildLocation = \\S0503TFS2T\TFSPlayground\ConsoleApplicationBuild\ConsoleApplicationBuild_20121210.23
DeploymentScriptDetails = agent1 | "$(BuildLocation)\Deploy.bat" $(BuildLocation) | c:\Env
LabEnvironmentUri = vstfs:///LabManagement/LabEnvironment/4
MaxWaitTime = 00:30:00
ThrowOnError = True
UseRoleForDeployment = True
Deployment Task Logs for Machine: win7testagent1
Access is denied
Exception Message: Team Foundation Server could not complete the deployment task for machine 'win7testagent1', script '"\\S0503TFS2T\TFSPlayground\ConsoleApplicationBuild\ConsoleApplicationBuild_20121210.23\Deploy.bat"', arguments '\\S0503TFS2T\TFSPlayground\ConsoleApplicationBuild\ConsoleApplicationBuild_20121210.23' and working directory 'c:\Env'. (type LabDeploymentProcessException)
Exception Stack Trace:
Server stack trace:
at Microsoft.TeamFoundation.Lab.Workflow.Activities.RunDeploymentTask.ExecuteDeploymentTask.RunCommand(AsyncState state)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
at System.Action`1.EndInvoke(IAsyncResult result)
at Microsoft.TeamFoundation.Lab.Workflow.Activities.RunDeploymentTask.ExecuteDeploymentTask.EndExecute(AsyncCodeActivityContext context, IAsyncResult result)
at System.Activities.AsyncCodeActivity.CompleteAsyncCodeActivityData.CompleteAsyncCodeActivityWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
Apparently, this is security issue, that i cannot get over it
Here's how this process is explained by MSDN:
The build-deploy-test workflow starts a build, and then gets the deployment scripts.
The build definition copies the build files to the drop location.
The workflow runs each deployment script in the working directory of the specific machine or machine role that the script is assigned to.
Each deployment script retrieves build files from the drop location.
Each deployment script copies or installs the specified build files onto machines in the lab environment.
At this point the problem shows up - the workflow runs each deployment script in the working directory of the specific machine.
Both machines are in the same domain the user that runs the Build service is also in the administrators group in the remote machine. I have even shared the remote folder where the workflow is supposed to copy the files/script with everyone in the network but no luck again.
I'm doing something stupid that driving me crazy - any help or thoughts are greatly appreciated!
Best,
Rado
The following solution may fix your problem.
Steps: Create local account on the following server: local lab service account - tfslab
tfs test controller server: create local tfslab account. Also configure the tfslab as lab service account in test controller configure console
tfs test agent server: create local tfslab account and add tfslab to local admin group. Also update Visual Studio Test Agent service and Visual Studio Lab Agent Service to run as tfslab.
tfs drop folder server: create local tfslab account. And add share read permission to tfs drop folder.
Details discussion see here.
You may try to check %ErrorLevel% at the last of your bat script. I met the same error, and it turned out that that error was caused by exit code of robocopy, which returns 1 when the copy successes. I set the error code to 0, the issue was fixed.
I'm trying to get TFS to automatically publish (not package at the moment) my web app on a build to a Win2k3 server with IIS6. The remote agent service is started.
The build fails giving me a 401. I'm now trying to manually run a cmd line from the build server itself (just incase the MSBUILD was doing something strange with the params set on the build definition) and it's giving me the same thing. Here is the command I'm trying to run:
msdeploy.exe
-source:contentPath='C:\Builds\1\Test\DummyTFSWebApp Submission Build\Binaries\_PublishedWebsites\DummyTFSWebApp'
-dest:contentPath='Default Web Site',
computerName='http://ipm-vm-dev/MSDEPLOYAGENTSERVICE',
userName='Domain\AdminUser',
password='Password',
authType='basic',
includeAcls='False'
-verb:sync -allowuntrusted
But like the build report, it's giving me:
I can't understand why! The username & password provided is an Administrator on the destination machine. I've even made the build server machine and admin (clutching at straws), and I've made the destination folder a share for everyone with write permission.
Help appreciated as this is really frustrating me!
I changed the authType='NTLM' and it now works!
/p:AuthType=NTLM
Hello I am trying to package and start up azure developement fabric on a windows 2008 server, I am so close yet still far. The steps I take are
1) run cspack.exe command /copyOnly to generate the .csx folder
2) run csrun.exe commmand /LaunchBrowser to start up the developement fabric and startup the browser
the error is as follows
System.BadImageFormatException: Could
not load file or assembly
'Interop.SSCE' or one of its
dependencies. An attempt was made to
load a program with an incorrect
format.
== Pre-bind state information === LOG: User = IP-0AE2B2DF\Administrator LOG:
DisplayName = Interop.SSCE (Partial)
LOG: Appbase =
file:///C:/Users/Administrator/Documents/Visual
Studio
2010/Projects/MyAzureProject/src/AzureCloudService/ServiceDefinition.csx/roles/MyAzureProject.Web/approot/
LOG: Initial PrivatePath =
C:\Users\Administrator\Documents\Visual
Studio
2010\Projects\MyAzureProject\src\AzureCloudService\ServiceDefinition.csx\roles\MyAzureProject.Web\approot\bin
Calling assembly : (Unknown).
=== LOG: This bind starts in default load context. LOG: Using application
configuration file:
C:\Users\Administrator\Documents\Visual
Studio
2010\Projects\MyAzureProject\src\AzureCloudService\ServiceDefinition.csx\roles\MyAzureProject.Web\approot\web.config
LOG: Using host configuration file:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Aspnet.config
LOG: Using machine configuration file
from
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Policy not being applied to
reference at this time (private,
custom, partial, or location-based
assembly bind). LOG: Attempting
download of new URL
file:///C:/Users/Administrator/AppData/Local/dftmp/s0/deployment(98)/res/deployment(98).AzureCloudService.MyAzureProject.Web.0/aspNetTemp/aspNetTemp/root/dfbc079a/82bed8d5/Interop.SSCE.DLL.
LOG: Attempting download of new URL
file:///C:/Users/Administrator/AppData/Local/dftmp/s0/deployment(98)/res/deployment(98).AzureCloudService.MyAzureProject.Web.0/aspNetTemp/aspNetTemp/root/dfbc079a/82bed8d5/Interop.SSCE/Interop.SSCE.DLL.
LOG: Attempting download of new URL
file:///C:/Users/Administrator/Documents/Visual
Studio
2010/Projects/MyAzureProject/src/AzureCloudService/ServiceDefinition.csx/roles/MyAzureProject.Web/approot/bin/Interop.SSCE.DLL.
ERR: Failed to complete setup of
assembly (hr = 0x8007000b). Probing
terminated.
this error happens with 2 dlls Interop.SSCE.DLL and SqlLite.dll Ive replaced all references to SqLite dll with a 64bit version and I dont have any references anymore to Interop.SSCE.DLL since I am not using it. Manually deleting these assemblies from the location
"C:\Users\Administrator\Documents\Visual Studio
2010\Projects\MyAzureProject\src\AzureCloudService\ServiceDefinition.csx\roles\MyAzureProject.Web\approot\bin"
solves the issue, but I dont obviously want to manually delete these everytime as I trying to automate a build process. My question is then how is the .csx folder actually generated and will this give me clues as to where these dll's are bring copied from? This is really frustrating as with the exception of those dll errors, I =m able to package the solution and startup the developement fabric with no other problems. Please Help!!
I realize this is old, but I just ran across it while trying to solve the same problem. In my case, the issue was that some of my projects were set to build x86 assemblies, instead of Any CPU. The solution was:
Go to Build -> Configuration Manager
Make sure "Active solution platform" is set to "Any CPU"
Make sure each of the projects also has the "Platform" set to "Any CPU"
Rebuild
Go to:
Tools > Options > Projects and Solutions > Web Projects
Check the Use the 64 bit version of IIS Express for web sites and projects.
This will ensure that your web project runs in x64 mode and will thus be able to use Service Fabric files.
Hope it helps...