Skip to main content

XM Cloud - Could not load file or assembly 'System.Net.Http.Formatting' or one of its dependencies

Hello Folks,

Today's blog post is to share one of the weirdest behavior i came across while working with Sitecore XM Cloud head repository.

I worked on it for couple of days, Created new projects for custom resolver and tested everything in local, and all the time i was using publishing profile and it was just working fine.

But out of the blue my local started getting below exception

Could not load file or assembly 'System.Net.Http.Formatting' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)


Looking at error you generally match dll versions, web.config had different bindings and bin also had same file but somehow my docker->deploy->Platform->bin was getting 5.2.6.0 version instead of 5.2.7.0

but suddenly i realized, my docker->deploy->Platform->bin should only have those DLLs which are my custom code, my project DLLs but it had all DLLs and that broke the whole site

So actual issue was my docker->deploy->platform->bin folder should only have those file which are either of custom projects & platform DLLs, but in my bin i had all sorts of DLLs being copied, see below screenshot, Instead of all DLLs, it should only have my custom DLLs of project.


 

So, I tried below steps 

1) I cleared package manager cache

2) Removed all reference of the project from platform & again redeployed

3) I changed from debug to release in publish profile configuration like below 

<LastUsedBuildConfiguration>Release</<LastUsedBuildConfiguration>

3) Deleted BIN and changed the publish folder path in my config to something else instead of platform, as out of the clue just wanted to see there is nothing related to that, but with my surprise it only copied my custom DLLs

4) I cleaned the project and build it again & republished again, and the most wired thing, it copied all those DLLs again and again i run into DLL hell issue of YSOD

Out of the clue i reached out to SLACK channel & Sitecore support for this behavior and they acknowledged that it is a bug currently in publishing profile & if you do not change anything and deploy, it copies all the DLLs & publishing profile target's are not working as expected.

Following is my OOTB platform.wpp.targets file which shipped with head repository 

https://github.com/sitecorelabs/xmcloud-foundation-head


 

Issue is with line no.16 where the " <Target Name="ExcludeSitecoreAssemblies" AfterTargets="Compile">" 

If you remove that line completely and make sure to restart your visual studio and do Clean & Publish, it will not only copy needed DLLs and everything will work

So finally my wpp file looks like below (Make sure to restart VS studio after the change)

As you can see in above image Target node is removed and now if i close my visual studio and do clean & build and publish again, it is only copying needed DLL and no more DLL hell issues 


Key take away & solution

1) Target tag which is available OOTB in wpp file works unpredictable

2) Publishing profile is misleading because, Sometime it works when we apply filter only when compilation happened, if no changes to the project it will publish everything. 

3) You have to remove Target tag from the wpp file & restart visual studio to make it work. 

NOTE: This was registered as a bug in Sitecore bug tracking system and reference number for this bug is 582640

I hope this will help other do not end up in the same issue as i did


Labels:

Comments

Post a Comment

Popular posts from this blog

Sitecore Technical Workshops - Top FAQs customers asked on XM Cloud

Hi Readers, I want to talk to you about interesting things which we have been doing which is "Technical Workshops" for our customers, so here goes the scenarios. So, we have been doing multiple types of technical workshops.  1) Training customer and their Sitecore technical team on latest and the greatest technologies like XM Cloud & Another composable stack and try enabling them for new Sitecore tech stack. 2) Customers / Potential Customers have their agenda of existing pain points, and we take a workshop on topics around them with best practices etc. little on new technologies, so they also know the future. Basically, we prepare custom targeted presentations & demos for individual workshops, and make sure it helps them answer their questions and they get insights of where Sitecore eco systems has to offer from their versatile toolset and try to keep them up to date with it. So, Purpose of this blog is, because in all these customer & their technical team's
Post a Comment
Read more

An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

You have noticed many times that everything was working fine and suddenly the below error starts coming and you find no way to work it out An error occurred while receiving the HTTP response to This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details. The reason for this is the receiving size of WCF service is smaller then the data which is coming from service It was working before because it was small,So you will have to try to increase the receiving setting in your end point,Possible settings can be following maxStringContentLength="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" maxArrayLength="2147483647" That would definately help you!!!
1 comment
Read more

Set up leprechaun code generation with Sitecore XM Cloud Starterkit

Hi Sitecorians, It has been amazing learning year so far and with the change in technology and shift of the focus on frontend frameworks and composable products, it has been market demand to keep learning and exploring new things. Reasons behind this blog Today's topic is something that was in my draft from April-May, and I always thought that there is already a good documentation out there for  Leprechaun  and a blog post is not needed, Until I realized that there was so many of us facing same kind of issues and same kind of problems and spending same amount of time, That is where I thought, if I could write something which can reduce that repetitive troubleshooting time, That would really help the community. 1)  In a project environment, if we get into some configuration issues, we resolve them, we make sure we are not blocked and continue, but if you think same issue, same step and same scenario will come to other people, so if we can draft it online, it will help other people 2
Post a Comment
Read more