Limiting the 64 assembly?

TinyCLR OS
1

Actually, my project has grown. And as soon as the number of assemblies exceeded 64, the project stopped deploying. The number of assemblies shown in the “Debug” window in VS does not match the number in the “Assembly listing” window in TinyCLR Config. Is this a bug or a special limitation?

Ending Normal Deployment:

   ...
   Assembly: Rpis.TinyCLR.Devices.Driver (2.1.0.0)  Attaching deployed file.
   Assembly: Rpis.TinyCLR.Devices.DeviceBase (2.1.0.0)  Attaching deployed file.
   Assembly: Rpis.TinyCLR.Drivers.Memory.SPI.FM25W256 (2.1.0.0)  Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.

End of deployment when the number of assemblies is more than 64:

   ...
   Assembly: Rpis.TinyCLR.Devices.DeviceBase (2.1.0.0)  Attaching deployed file.
   Assembly: Rpis.TinyCLR.Drivers.Memory.SPI.FM25W256 (2.1.0.0)  Resolving.
Link failure: some assembly references cannot be resolved!!

Assembly: Rpis.TinyCLR.Devices.Driver.Sk3_50_2 (1.0.0.0) needs assembly 'Rpis.TinyCLR.Drivers.Memory.SPI.FM25W256' (2.1.0.0)
Assembly: Rpis.TinyCLR.Devices.Sk3_50_2 (1.0.0.0) needs assembly 'Rpis.TinyCLR.Devices.Driver.Sk3_50_2' (1.0.0.0)
Error: a3000000
Waiting for debug commands...
2

We will try it out but I do not see why this might be the case! Assembly count limit · Issue #1018 · ghi-electronics/TinyCLR-Libraries · GitHub

Could it an assembly name/? or assembly size? Did you try different assemblies?

3

I think one of assembly still use mismatch version. Make sure your project is clean up.

4

I’ve tried the following order:

  1. 64 assemblies. The project is in the deployment stage.
  2. Added my new assembly Rpis.TinyCLR.Service.ObjectCreator (about 4KB size). 65 assemblies. The project is not deployed.
  3. Added GHIElectronics.TinyCLR.Data.Json. 66 assemblies. The project is not deployed.
  4. Added GHIElectronics.TinyCLR.Cryptography. 67 assemblies. The project is not deployed.
  5. Deleted my assembly named Rpis.TinyCLR.Service.ObjectCreator. 66 assemblies. The project is not deployed.
  6. Removed GHIElectronics.TinyCLR.Cryptography. 65 assemblies. The project is not deployed.
  7. Removed GHIElectronics.TinyCLR.Data.Json. 64 assemblies. The project is deployed again.

There are many nuget packages in my project. I’m afraid that I will have to reconsider the project’s build architecture and use sources instead of packages.

Unfortunately no. First of all, I checked for the consistency of versions of all packages and assemblies, cleaned and rebuilt the solution, and cleared the application from the module’s memory. And I did this at every step described above.

If you give me some ideas, then tomorrow I’ll try something else.

5

  • Stop at 64 assemblies, make sure deploy is OK.

  • Create a new simple assembly that not include anything, just add simple function and return 0.

  • Use that assembly for 65th to see if any error.

6

At your suggestion, I made a test project from assembly stubs. It shows the problem well. By commenting - uncommenting the assembly call lines it is easy to reproduce the error.

1 Like
7

CLR\Include\TinyCLR_Runtime.h: static const int c_MaxAssemblies = 64;

From the original netmf firmware source code - the table of assemblies is only 64 entries long. This is baked into the firmware.

EDIT: Whatever the limit is set too, there’s an opportunity to update the deployment code to throw an error if you exceed the limit. There’s also a size limit on assemblies (64Kb I think?) and that does throw an error if you exceed it. Overall, what this means is that the max size of your program is 64 assemblies of 64kb of MSIL each. That’s not a hard limit on deployment size - resources don’t count against this. I have deployed multiple megabytes of resources.

3 Likes
8

By the way, you can cheat the system a bit here. I did some code for Justin’s Radius watch experiment where the apps were stored in external flash. I would then load them dynamically and execute them from RAM. So, you can cheat the limit (at a cost to runtime speed and RAM) by loading assemblies from resources or from a filesystem and dynamically loading them.

Note that this is mostly applicable to situations where the assemblies are a dynamic set of assemblies that are not all needed at once.

For the use case you seem to be facing, you will be far better off to merge assemblies until you hit the full 64 x 64kb limits.

2 Likes
9

No need to refactor your source code either : GitHub - dotnet/ILMerge: ILMerge is a static linker for .NET Assemblies.

2 Likes
10

oh cool! This can easily be increased in the future is my guess. We will look into ti, thanks @mcalsyn

3 Likes
11

I follow this. This is one of the reasons why there are so many assemblies. But I ran into the problem of restrictions on the other side.

The problem is that almost all of them are needed at the same time. :slight_smile:
Dynamically loading will probably turn out to be 10%. And the project is not finished yet.
With the combination of assemblies - an interesting idea. I will try as time will be, but for now I use the sources.

By the way, the question is, but this garbage, also from NETMF stretches? (the string generated for an example, the size may differ)

Failed to generate device specific assemblies:
Exceeded maximum size of string table: 35992
MMP: error MMP0000: CLR_E_OUT_OF_MEMORY