[NET6] Updating C1 installation: trouble with "assets.cache" file

[NET6] Updating C1 installation: trouble with "assets.cache" file

Posted by: wknauf on 8 December 2022, 7:03 am EST

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 8 December 2022, 7:03 am EST - Updated 13 August 2025, 11:03 am EST

  Hi C1,

  I assume this is actually a problem of “System.Resources.Extensions”, but I start asking here, as it happens for me with your component.

  I updated my installation to 6.0.20223.584. But our projects still use the C1 components with version .576 (using Nuget packages). All C1 stuff did not resolve and caused compilation errors. I tracked the reason to this warning:

  Warning MSB3106 Assembly strong name “:\Program Files %28x86%29\ComponentOne\WinForms Edition\bin\v6\c1.win.printing\6.0.20222.576\lib\net6.0\C1.Win.PrintPreview.6.dll” is either a path which could not be found or it is a full assembly name which is badly formed. If it is a full assembly name it may contain characters that need to be escaped with backslash(). Those characters are Equals(=), Comma(,), Quote("), Apostrophe('), Backslash().

  I tracked it down to a file “obj\Debug\net6.0-windows\projectname.assets.cache”: the path to the dll points to “program files” instead of the nuget package cache (“C:\Users\USERNAME.nuget\packages\c1.win.printing\6.0.20222.576\lib\net6.0\C1.Win.PrintPreview.6.dll”).

  This file seems to be created by the “System.Resources.Extensions”, which is required e.g. if you use strong types resource files.

  Attached sample reproduces the problem - but you will probably see only the issue that the assets file contains a path in “program files” instead of the path in the nuget package, but there will be no compilation error.
  
  To reproduce it, you have to change the package version to 576 and compile the solution on a machine where the .576 components are installed. Then copy the solution (including bin and obj folders) to another machine where .584 is installed. Here the warning should happen.

  C1PrintTest.zip

  The workaround is quite simple: delete all “obj” folders after updating C1.

  I think the problem is that the “System.Resources.Extension” does not pick the paths from the Nuget package but from the local installation.
  
  But if I create an issue at https://github.com/dotnet/runtime, they will probably tell me that they cannot reproduce it as they would need a C1 installation.
  
  What do you think? How to continue this?

  Best regards

  Wolfgang

• 

  avnish.kumar

  

  • Post Options:
  • Link
    Copy

  Posted 12 December 2022, 5:11 am EST

  Hi Wolfgang,

  We checked the issue at our end and it seems to be occurring when the Nuget packages were referred from the local repository. The local path of the DLL is added when the Nuget package is installed from a local folder.
  
  Could you please try the same scenario after installing the Nuget packages from nuget.org as the PackageSource?

  Also, we did not face any errors during Build, we did see the warning but the build worked fine.
  
  We have escalated the case to the development team to get their insights on this and will let you know as soon as we have an update.
  
  [Internal Tracking ID: C1WIN-28754]

  Regards
  
  Avnish

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 12 December 2022, 11:39 am EST

  Hi Avnish,

  the build errors are probably hard to reproduce. You would have to add the .576 nuget package to your project while having installed the .576 version in “c:\Program Files”. Then, update the installation to .584. When you compile the solution again, the issue should occur.
  
  And the error disappears when the “obj” directory is deleted.

  I just noticed that the wrong paths are also in the file “obj\project.nuget.cache”:

   "expectedPackageFiles": [
      "C:\\Users\\USERNAME\\.nuget\\packages\\c1.win\\6.0.20223.584\\c1.win.6.0.20223.584.nupkg.sha512",
      "C:\\Program Files (x86)\\ComponentOne\\WinForms Edition\\bin\\v6\\c1.win.barcode\\6.0.20223.584\\c1.win.barcode.6.0.20223.584.nupkg.sha512",
      "C:\\Program Files (x86)\\ComponentOne\\WinForms Edition\\bin\\v6\\c1.win.printing\\6.0.20223.584\\c1.win.printing.6.0.20223.584.nupkg.sha512",
      "C:\\Program Files (x86)\\ComponentOne\\WinForms Edition\\bin\\v6\\c1.win.ribbon\\6.0.20223.584\\c1.win.ribbon.6.0.20223.584.nupkg.sha512",
      "C:\\Program Files (x86)\\ComponentOne\\WinForms Edition\\bin\\v6\\c1.win.splitcontainer\\6.0.20223.584\\c1.win.splitcontainer.6.0.20223.584.nupkg.sha512",
      "C:\\Program Files (x86)\\ComponentOne\\WinForms Edition\\bin\\v6\\c1.win.supertooltip\\6.0.20223.584\\c1.win.supertooltip.6.0.20223.584.nupkg.sha512",
      "C:\\Users\\USERNAME\\.nuget\\packages\\c1.zip\\2.0.20202.1\\c1.zip.2.0.20202.1.nupkg.sha512",
  

  Best regards

  Wolfgang

• 

  avnish.kumar

  

  • Post Options:
  • Link
    Copy

  Posted 13 December 2022, 5:01 am EST

  Hi Wolfgang,

  We have forwarded the information to the development team. We will update you as soon as we hear from them.

  We also observed that the cache files get auto-updated if you update the Nuget Packages. And we were also not able to replicate the issue if we refer to the Nuget Packages from the nuget.org package source instead of the offline package source.

  Regards
  
  Avnish

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 13 December 2022, 10:12 am EST - Updated 13 August 2025, 11:10 am EST

  I added the package from Nuget.org.

  My Visual Studio settings also contain C1 repositories, but I don’t think that the assets cache points to them.
  
  

  

  744×434 18.7 KB

  My screenshot also contains a testing repository (blanked out), but this definitively does not contain C1 packages.

  Best regards

  Wolfgang

• 

  avnish.kumar

  

  • Post Options:
  • Link
    Copy

  Posted 15 December 2022, 2:48 pm EST

  Hi Wolfgang,

  Thank you for providing the information. We have relayed the information to the development team and will let you know as soon as we get any update.

  Regards
  
  Avnish

• 

  avnish.kumar

  

  • Post Options:
  • Link
    Copy

  Posted 20 December 2022, 11:22 pm EST

  Hi,

  The development team has asked if you could provide a GIF showing the warnings and the errors you are getting at your end.

  Regards
  
  Avnish

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 21 December 2022, 6:02 am EST

  Hi Avnish,

  this would be difficult to reproduce, hope we can avoid this.

  I first would have to downgrade my installation to .576, then create a project targeting the .576 Nuget packages of C1 (or open the project from my initial sample and compile it and close VS again), then upgrade my installation to .584 again. And now the warning/error should happen when the sample project is built again.

  If this does not provide the necessary information, let’s close the ticket.

  Best regards

  Wolfgang

• 

  avnish.kumar

  

  • Post Options:
  • Link
    Copy

  Posted 23 December 2022, 12:43 am EST

  Hi Wolfgang,

  The issue was replicated a couple of times at our end but we could not record it then.
  
  We would request that you also try and share the video with us if it replicates.

  We will try to replicate the issue again and share any updates.

  Regards
  
  Avnish

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 23 December 2022, 10:51 am EST - Updated 23 December 2022, 10:56 am EST

  I can reproduce it, and I think I know why you could reproduce it only a few times: it will not happen if your local Nuget cache contains “C:\Users\USERNAME.nuget\packages\c1.win.printing\6.0.20222.576”. I just noticed that for me, this directory was created one day after my initial bug report. So, Visual Studio/Nuget picked the files from somewhere else (maybe from the cache in “C:\Program Files (x86)\ComponentOne\Packages”?), instead of downloading them from Nuget central.
  
  Attached is a modified sample with some cleanup, and it really uses C1PrintDocument now ;-): C1PrintTest_576.zip

  Here are the first few steps to prepare the issue:
  
  
  
  C1 .576 is installed, and I open the solution and build it. Then I show “obj\project.nuget.cache”. The final step is that I show my Nuget cache, where I renamed the old dir “6.0.20222.576” to “6.0.20222.5760” to show that it is not downloaded.

  And here are the final steps:
  
  
  
  After installation .584, I prove that “obj\project.nuget.cache” still contains the old path, then I open VS and build the solution => the error occurs.

  Hope this makes it reproduceable for you. The important step seems to be to remove .576 from your local Nuget repository before compiling with .576 installed.

  Best regards

  Wolfgang

• 

  prabhat.sharma

  

  • Post Options:
  • Link
    Copy

  Posted 26 December 2022, 5:38 am EST

  Hello Wolfgang,

  Thank you for the detailed steps.
  
  We are discussing this with the development team and will get back to you with the updates soon.

  Regards,
  
  Prabhat Sharma.

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 23 October 2023, 8:28 am EST

  Hi,

  any updates from the developers? This is a bit annoying, as it hits as with every C1 update.

  Best regards

  Wolfgang

• 

  prabhat.sharma

  

  • Post Options:
  • Link
    Copy

  Posted 1 November 2023, 8:24 am EST

  Hello Wolfgang,

  As per the developers, obj\Debug\net6.0-windows*.assests.cache has mentions of the location where the dll is fetched from.

  You can simply do a clean solution and then rebuild to solve this.
  
  Please let us know if it helps. If you have any other thoughts then please let us know.

  Regards,
  
  Prabhat Sharma.

• 

  wknauf

  • Post Options:
  • Link
    Copy

  Posted 2 November 2023, 4:58 am EST

  OK, I will check whether “Clean” works after the next C1-Update.

  Best regards

  Wolfgang