Failed to deploy component - "Cannot deserialize the current JSON object ..."
Asked Answered
Q

3

7

Background Information

  • TFS 2015 RC2
  • Release Management Server 2015
  • Azure VM with 2015 deployment agent
  • Physical local machine with 2015 deployment agent

Both machines need the drop location using the Through Release Management Server over HTTP(S) option. Currently we are using the HTTP side of things over port 1000.

Workflow

  1. Stop App Pool (Working)
  2. Stop Website (Working)
  3. Copy website directory to backup location (Working)
  4. Backup Database (Working)
  5. Deploy Component (Not Working), using either
    • xcopy
    • msdeploy (web deploy package)

The Error (TL;DR)
The same error is received every time, it doesn't matter which machine or which deployment method. The component always fails with a JSON.NET issue.

7/22/2015 3:03:39 PM - Error - (13704, 104) - Cannot deserialize the current JSON object (e.g. {"name":"value"}) into type 'System.String[]' because the type requires a JSON array (e.g. [1,2,3]) to deserialize correctly.
To fix this error either change the JSON to a JSON array (e.g. [1,2,3]) or change the deserialized type so that it is a normal .NET type (e.g. not a primitive type like integer, not a collection type like an array or List<T>) that can be deserialized from a JSON object. JsonObjectAttribute can also be added to the type to force it to deserialize from a JSON object.
Path 'ErrorMessage', line 1, position 16.: \r\n\r\n   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   at Microsoft.TeamFoundation.Release.Data.Proxy.RestProxy.BaseDeploymentControllerServiceProxy.GetPackageFileInfos(String packageLocation)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.HttpPackageDownloader.CopyPackageAndUnpackIt(String packageSourceLocation, String filesDestinationLocation)
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.ComponentProcessor.CopyComponentFiles()
   at Microsoft.TeamFoundation.Release.DeploymentAgent.Services.Deployer.ComponentProcessor.DeployComponent()

Update (Workaround)
As a work around if I edit the build configuration to have a UNC path as the drop location, the deployment is successful. However I want to use the Copy build output to server option.

Qualifier answered 24/7, 2015 at 6:36 Comment(2)
AFAIK Release Management can't work with build artifacts stored on the server -- you have to put them on a UNC path.Steamer
@DanielMann Thanks I thought this might be the case but Microsoft MSDN Support seem to think otherwise... I am still waiting for them to get back to me at the moment. It seems odd because the "UNC" path is just next to the "Build" path i.e. C:\Builds\xxx and C:\Drop\xxx. The service user has full access to the server and target machines.Qualifier
B
0

Un-installing deployer and installing RM 2015 RTM deployer should fix this issue.

There was an issue in previous RM releases where NewtonSoft.Json dll was not getting upgraded during deployer auto upgrade.

Burtburta answered 30/7, 2015 at 12:59 Comment(1)
The deployer was not upgrade from a 2013 deployer. The deployer was also first installed as RTM version.Qualifier
S
0

I dont think MS really tested the agent releases with Update 1. I got the same error which is actually just a generic error message when using deployment through HTTP. When I converted it to deployment through UNC paths I found out what the problem was.

As you might know with TFS 2015 you had to name the release components exactly as the artifact names. So artifact 'WebApp X' has a release component called 'WebApp X' in RM with the subpath 'WebApp X'.

In my release configuration I have 3 different components (and artifacts). So on the disk it was:

  • '\build\WebApp X'
  • '\build\WebApp Y'
  • '\build\WebApp Z'

Worked perfectly with 2015 RTM. Now after Update 1 it looks for the following:

  • '\build\WebApp X\WebApp X'
  • '\build\WebApp X\WebApp Y\'
  • '\build'WebApp X\WebApp Z'

I dont know why it does this and how to solve this yet, but I manually altered the folders in the artifacts drop location and RM picked it up fine. So still looking how to fix this that it works correctly.

Somato answered 4/1, 2016 at 16:29 Comment(1)
This is a known regression. I had this same problem, and contacted [email protected] explaining the issue. They sent me a .dll to replace and everything has worked as expected since.Hanhhank
I
0

This json issue occurs if the user under which the RM server app pool is running doesnt have access to the drop location of the component and you have selected 'Through RM server http(s) option'

So as a fix, you can give the app pool user permissions to access the drop.  you can see the correct error in the server logs. "Package location '\share\' does not exists or Application Pool user does not have access"

Intrigant answered 4/2, 2016 at 8:7 Comment(1)
This is not the cause of the issue, the issue is the desired setup is not current supported.Qualifier

© 2022 - 2024 — McMap. All rights reserved.