You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
3P plugin authors will reference the MGC nuget package in their plugin. The typical pattern is to have a build step that copies the MGC dll that they build against into the dist folder. This will overwrite the dll that was packaged with the emitter from npm, which could lead to runtime errors if the version of the emitter is not compatible with the version of MGC.
In order to ensure that there are no incompatibilities, we could add logic into our npm publish workflow that stores off the versions of the MGC and MGC.CM dlls in a metadata file. As part of the npm build step, we would compare the versions in the dist folder to this metadata file, and error out if they are not the same.
Another possible approach is to establish a convention where the versions for the emitter and the nuget packages are always identical. This convention would make it clear which Nuget/emitter versions are being used without digging into the dist. It wouldn't prevent users from deviating but it would be more of a convention that we would need to document. We would still want to have a check in the emitter to guide users to the correct version.
The text was updated successfully, but these errors were encountered:
3P plugin authors will reference the MGC nuget package in their plugin. The typical pattern is to have a build step that copies the MGC dll that they build against into the dist folder. This will overwrite the dll that was packaged with the emitter from npm, which could lead to runtime errors if the version of the emitter is not compatible with the version of MGC.
In order to ensure that there are no incompatibilities, we could add logic into our npm publish workflow that stores off the versions of the MGC and MGC.CM dlls in a metadata file. As part of the npm build step, we would compare the versions in the dist folder to this metadata file, and error out if they are not the same.
Another possible approach is to establish a convention where the versions for the emitter and the nuget packages are always identical. This convention would make it clear which Nuget/emitter versions are being used without digging into the dist. It wouldn't prevent users from deviating but it would be more of a convention that we would need to document. We would still want to have a check in the emitter to guide users to the correct version.
The text was updated successfully, but these errors were encountered: