Fix error handling in PluginsManager and plugins query, fixed postbuild script duplicate deletion during build

[jjw24]

• Fix wrong error message for PluginsManager
• Added try catch for install plugin call
• Added try catch for querying plugin and plugins tasks
• Fixed postbuild script to remove duplicate with the condition that the versions are the same. Specific to issue 256, the direct package reference (ICSharpCode.SharpZipLib 1.2.0) used by PluginsManager has a different version to the output of other packages' ICSharpCode.SharpZipLib (0.86) dependency.

Closing #256

[taooceros]

Would you please add a continue with for the task that do the query jobs of Plugins to catch the exception thrown by Plugins? There is an option that will only run the continue with on fault, which means error thrown.

[taooceros]

Would you please add a continue with for the task that do the query jobs of Plugins to catch the exception thrown by Plugins? There is an option that will only run the continue with on fault, which means error thrown.

Or maybe a try catch within the parallel. Foreach to catch the error and throw them to log.

[taooceros]

@jjw24 I added the exception handling for plugin querying, please check.

[jjw24]

@jjw24 I added the exception handling for plugin querying, please check.

looks good, thank you

[taooceros]

Just a question before approval, why should we have different version of the same dll reference? I don't believe we use sharpziplib in other places than our PluginsManager, so why should that fix it?

[jjw24]

not as a direct reference, but some assemblies possibly in Infrastrucutre project use it as an indirect reference (different version) as far as i understand, which results in the dll being outputted in the parent folder. Additionally our default plugins still reference Infrastructure, and because we need plugins to output all dlls, the indirect referenced sharpziplib is also being outputted in those plugins.

[taooceros]

Just a question before approval, why should we have different version of the same dll reference? I don't believe we use sharpziplib in other places than our PluginsManager, so why should that fix it?

not as a direct reference, but some assemblies possibly in Infrastrucutre project use it as an indirect reference (different version) as far as i understand, which results in the dll being outputted in the parent folder. Additionally our default plugins still reference Infrastructure, and because we need plugins to output all dlls, the indirect referenced sharpziplib is also being outputted in those plugins.

Oh you are right, but why don't we make those version the same? Since the only reason we reference to Infrastructure is that this plugin is native.

[jjw24]

Just a question before approval, why should we have different version of the same dll reference? I don't believe we use sharpziplib in other places than our PluginsManager, so why should that fix it?

not as a direct reference, but some assemblies possibly in Infrastrucutre project use it as an indirect reference (different version) as far as i understand, which results in the dll being outputted in the parent folder. Additionally our default plugins still reference Infrastructure, and because we need plugins to output all dlls, the indirect referenced sharpziplib is also being outputted in those plugins.

Oh you are right, but why don't we make those version the same? Since the only reason we reference to Infrastructure is that this plugin is native.

well our direct reference is 1.2.0, the indirect one is 0.89. Dont think there is a easy way to lift the other assemblies' referenced version

[taooceros]

Just a question before approval, why should we have different version of the same dll reference? I don't believe we use sharpziplib in other places than our PluginsManager, so why should that fix it?

not as a direct reference, but some assemblies possibly in Infrastrucutre project use it as an indirect reference (different version) as far as i understand, which results in the dll being outputted in the parent folder. Additionally our default plugins still reference Infrastructure, and because we need plugins to output all dlls, the indirect referenced sharpziplib is also being outputted in those plugins.

Oh you are right, but why don't we make those version the same? Since the only reason we reference to Infrastructure is that this plugin is native.

well our direct reference is 1.2.0, the indirect one is 0.89. Dont think there is a easy way to lift the other assemblies' referenced version

hmmm you are right. Maybe we should take a look later, but merging this now.