Hello,
Integration is really complicated ! I have tons of problems dues to incompatibilities with lattest .net versions and use of outdated version of some packages like CodeAnalysis. My project is composed of a mix of .Net Standard, .Net Core and .Net Framework assemblies, all sharing Dlls... and et this time, integration is a nightmare !
NuGet integration do not work if I'm not including some assembly staticly - and it is linked with a very high number of assembly (SQL...? Crypto ?). I have tried to use demo assemblies, but dependancies are much more older.
I've spend a half a day to make it work (the CsLexer) on one of my dev machine, and have to do the same on the other one ! And it do not work anymore... Some assemblies do not loads, version a the bad ones.
:-[
I know that .Net had a lot of limitations, it may be complicated for you to manage Roslyn assemblies for all situations.
What is the best method to Integrate it ?
Thank you.
Best regards.
Hello,
I have solved my problems with a solution that seems to run everywhere (I mean, on all my dev machines). To limits conflicts I use the AssemblyResolve event of AppDomaine.
Steps :
- Create a directory in the project, and put in all Alternet DLL found in the demo binary directory (ok, I have to check the needed one...).
- Create a Handler for the ResolveAssembly : this must search in the directory first.
Here the code :
static string FindAssemblyIn(string path, string name)
{
name = name.Contains(",") ? name.Substring(0, name.IndexOf(",")) : name;
var f = Directory.GetFiles(path, "*.*", SearchOption.AllDirectories)
.Where(r => Path.GetFileName(r).StartsWith(name))
.FirstOrDefault();
return f;
}
static Assembly AssemblyResolveHandler(object source, ResolveEventArgs e)
{
Console.WriteLine("Resolving {0}", e.Name);
var f = FindAssemblyIn(Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "AlternetAssemblies"), e.Name);
if (f == null)
f = FindAssemblyIn(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), e.Name);
if (f == null)
throw new Exception("No dll found matching this name : " + e.Name);
return Assembly.LoadFrom(f);
}
Thank you !
I have solved my problems with a solution that seems to run everywhere (I mean, on all my dev machines). To limits conflicts I use the AssemblyResolve event of AppDomaine.
Steps :
- Create a directory in the project, and put in all Alternet DLL found in the demo binary directory (ok, I have to check the needed one...).
- Create a Handler for the ResolveAssembly : this must search in the directory first.
Here the code :
static string FindAssemblyIn(string path, string name)
{
name = name.Contains(",") ? name.Substring(0, name.IndexOf(",")) : name;
var f = Directory.GetFiles(path, "*.*", SearchOption.AllDirectories)
.Where(r => Path.GetFileName(r).StartsWith(name))
.FirstOrDefault();
return f;
}
static Assembly AssemblyResolveHandler(object source, ResolveEventArgs e)
{
Console.WriteLine("Resolving {0}", e.Name);
var f = FindAssemblyIn(Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "AlternetAssemblies"), e.Name);
if (f == null)
f = FindAssemblyIn(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), e.Name);
if (f == null)
throw new Exception("No dll found matching this name : " + e.Name);
return Assembly.LoadFrom(f);
}
Thank you !
Hello,
I'm sorry to hear about all inconveniences you're having integrating our products.
These assemblies (crypto,SQL, etc.) come as dependent assemblies of CodeAnalysis package (version 2.10). It looks the list of these assemblies is much smaller for version 3.1, which we will support very shortly.
Could I ask you to send me (andrew.medvedev@alternetsoft.com) a sample demo project where nuget packages do not work without using AssemblyResolve handler, so we can investigate why it's not working, as it seems to work fine on our tests.
regards,
Andrew
I'm sorry to hear about all inconveniences you're having integrating our products.
These assemblies (crypto,SQL, etc.) come as dependent assemblies of CodeAnalysis package (version 2.10). It looks the list of these assemblies is much smaller for version 3.1, which we will support very shortly.
Could I ask you to send me (andrew.medvedev@alternetsoft.com) a sample demo project where nuget packages do not work without using AssemblyResolve handler, so we can investigate why it's not working, as it seems to work fine on our tests.
regards,
Andrew
Hello,
I think that you only have to create a projet that is using different CodeAnalysis version than yours, and use this project in another WinForm project that is using the Editor and the C# Lexer. It will conflit and then, some structure (that have been changed between CodeAnalysis versions) cannot be found in the assemblies, or loading exception will be thrown because assembly signature is not the same than the one found in the directory, or dependencies will fail to load (most of my cases). For exemple, Alternnet need 1.3.1 and another component in the application need 3.1, and then there is one looser depending on wich assembly are taken. If you have another NuGet package that need the CodeAnalysis too, it is insoluble. So, in this case, the solution to put all dependecies in a directory (like if they were in specific installation directory, or in the GAC) seems to be a dirty but efficient solution. I say "seems" because I haven't investigate suffitiently to be sure this a real, all time working solution - or even if I have really understand what's hapen !
Fundamentally, we have to be able to take assemblies, staticly link them in a project (as file), and run it. Contiuous integration need such abilities. We need that a new dev come with his laptop, load the project from Git and run tests and app immediatly.
I don't know if I am alone with such problems. I have undersand lot of mechanisms, linked with app.manifest and Nugets package registration.
Overall, it is really efficient components. At this time, I think you should enhance some points :
- Documentation : event in the code, it seems that big components have non in-code doc (no comments explannations). I haven't found any deep documentation.
- Theming is too complicated, and it is not complete. For exemple, icons are not adapted to black background : it is really not good looking. You have to make ALL components skinned and icons coherent with the skin.
- Dependencies : I don't know how you chould manage this.
Regards.
I think that you only have to create a projet that is using different CodeAnalysis version than yours, and use this project in another WinForm project that is using the Editor and the C# Lexer. It will conflit and then, some structure (that have been changed between CodeAnalysis versions) cannot be found in the assemblies, or loading exception will be thrown because assembly signature is not the same than the one found in the directory, or dependencies will fail to load (most of my cases). For exemple, Alternnet need 1.3.1 and another component in the application need 3.1, and then there is one looser depending on wich assembly are taken. If you have another NuGet package that need the CodeAnalysis too, it is insoluble. So, in this case, the solution to put all dependecies in a directory (like if they were in specific installation directory, or in the GAC) seems to be a dirty but efficient solution. I say "seems" because I haven't investigate suffitiently to be sure this a real, all time working solution - or even if I have really understand what's hapen !
Fundamentally, we have to be able to take assemblies, staticly link them in a project (as file), and run it. Contiuous integration need such abilities. We need that a new dev come with his laptop, load the project from Git and run tests and app immediatly.
I don't know if I am alone with such problems. I have undersand lot of mechanisms, linked with app.manifest and Nugets package registration.
Overall, it is really efficient components. At this time, I think you should enhance some points :
- Documentation : event in the code, it seems that big components have non in-code doc (no comments explannations). I haven't found any deep documentation.
- Theming is too complicated, and it is not complete. For exemple, icons are not adapted to black background : it is really not good looking. You have to make ALL components skinned and icons coherent with the skin.
- Dependencies : I don't know how you chould manage this.
Regards.
Hello,
Thank you again for your feedback.
With dependencies the only thing we could think of is to always support the latest version of these packages for the given version of Framework, which would not solve a problem if earlier version is used by other component or the project itself. It does not look like there is a universal solution in case different versions of the same package are used in the project, but there are few ways of resolving it, including handling AssemblyResolve event. Here is a bit more information related to this issue:
https://michaelscodingspot.com/how-to-resolve-net-reference-and-nuget-package-version-conflicts/
With documentation, we do have xml-comments for most public classes/interfaces/methods/properties, which are used in intellisense; however these comments are not really elaborate.
We do have a constant thread of activities in this area, but we have to balance it against development work.
There are also user-guides that we supply, outlining high-level structure of our libraries and providing some step-by-step examples.
With theming, we've scheduled a support for skinning/theming to the next major update (expected within 6 months).
regards,
Andrew
Thank you again for your feedback.
With dependencies the only thing we could think of is to always support the latest version of these packages for the given version of Framework, which would not solve a problem if earlier version is used by other component or the project itself. It does not look like there is a universal solution in case different versions of the same package are used in the project, but there are few ways of resolving it, including handling AssemblyResolve event. Here is a bit more information related to this issue:
https://michaelscodingspot.com/how-to-resolve-net-reference-and-nuget-package-version-conflicts/
With documentation, we do have xml-comments for most public classes/interfaces/methods/properties, which are used in intellisense; however these comments are not really elaborate.
We do have a constant thread of activities in this area, but we have to balance it against development work.
There are also user-guides that we supply, outlining high-level structure of our libraries and providing some step-by-step examples.
With theming, we've scheduled a support for skinning/theming to the next major update (expected within 6 months).
regards,
Andrew
Hello,
are there any news on v3.1? Is there a workaround to use the newest roslyn nuget packages?
Thanks
are there any news on v3.1? Is there a workaround to use the newest roslyn nuget packages?
Thanks
Hello Andi,
Yes, we're testing compatibility with Roslyn 3.1 right now.
We plan to release new version of Extensibility Studio and nuget packages compatible with Roslyn 3.1 end of August.
regards,
Andrew
Yes, we're testing compatibility with Roslyn 3.1 right now.
We plan to release new version of Extensibility Studio and nuget packages compatible with Roslyn 3.1 end of August.
regards,
Andrew