SyntaxEditor.Document Control is missing in the newer version?

You mentioned you are upgrading from a previous version.  If you haven't already, please refer to the conversion notes starting with the first version after your previous version and work your way through to v23.1.

You did not mention the version you were on previously, but the reference to SyntaxEditor.Document implies you might have been on a version prior to v20.1.  If so, that release involved a major rewrite (mentioned here) that, unforutnately, means the prior API is not compatible with the new API.  You'll need to refer to the extensive product documentation and many samples to learn how to use the latest version of the product.

If your previous version was at least v20.1 and the conversion notes do not resolve the issue, please post the exact error message you are receiving and let us know the prior version you were on before the upgrade.

Actiprosoftware.SyntaxEditor.Addons.Dotnet.Net20.dll Version 1.0.103.0

Actiprosoftware.Shared.Net20.dll  Version 1.0.103.0

Actiprosoftware.syntaxEditor.Net20.dll version 4.0.283.0

Actiprosoftware.WincoreUI.Net20.dll version 1.0.103.0

we are using these 4 dll in our old project now i am migrating the application from .net framework 4 to .net framework 4.8.1. in our project we have used this actiprosoftware control for TextEditor and document control and also for dynamicoutliningsyntaxLanguage.I am not able to find out this classname and document control in the newer version of actiprosoftware.could you please guide me for the latest version.

Thanks in advance

The document "control" does not exist in the newer framework. There is still a document class, but it is not a user control.  The SyntaxEditor.Document property defines the current document, and it is initialized with a default value.  This property expects a class that implements the IEditorDocument interface, and most users will utilize our EditorDocument class.  Even so, the SyntaxEditor.Document property is pre-populated with a document instance, so you shouldn't need to assign it a new document unless you are wanting to use the document swapping feature.

I should note that migrating from .NET 4.0 to .NET 4.8 should not require moving to new versions of our controls since .NET Framework is backwards compatible.  You might find it easier to first move your project to .NET 4.8 with the existing controls and ensure everything is working as expected before attempting to upgrade the controls.  That will help isolate if any compiler errors are related to the newer .NET Framework target or the newer controls.

If you do want to update to the latest controls from a version that old, you will not be able to do so using existing designer code.  Any code serialized by the Visual Studio designer for that version is not compatible with the newer API's.  An approach you might follow could be:

1. Ensure your solution compiles with .NET 4.0 and backup all your files.
2. Change your project targets to .NET 4.8.x and ensure your solution still compiles.
3. Make a note of which projects are currently using the older Actipro assemblies and which ones.
4. Open the Visual Studio designer for any Forms or UserControls that use Actipro controls
   1. Make a note of which ones used which controls.
   2. Make a note of the control names.
   3. Make a note of any non-default property values and events that are being monitored.
   4. Delete the control instances from the designer.
5. Deleting the controls will typically result in syntax errors for any references to those controls.  Comment out any code that referenced Actipro controls and leave a "TODO:" comment that the code needs to be restored.  Repeat this until the solution compiles again.
6. Remove all references to the older assemblies from all projects.
7. Refer to the Converting to v12.1 topic for a list of which newer assemblies map to the older assemblies and add references to those assemblies.  You should need:
   1. ActiproSoftware.Shared.WinForms.dll
   2. ActiproSoftware.Text.WinForms.dll
   3. ActiproSoftware.Text.LLParser.WinForms.dll
   4. ActiproSoftware.Text.Addons.DotNet.WinForms.dll
   5. ActiproSoftware.SyntaxEditor.WinForms.dll
   6. ActiproSoftware.SyntaxEditor.Addons.DotNet.WinForms.dll
8. Refer to the Converting to v21.1 topic for a list of namespace changes that were made.  Using find-and-replace functionality of Visual Studio, you should be able update all your using statements to the new namespaces by following the list in the topic. The replacements should be performed in the order listed.
9. At this point you may still have compiler errors.
   1. If any using statements are giving errors, remove the statement and address any unresolved types one-by-one. If Visual Studio finds an unresolved type, it will suggest the using statements you need.
   2. For any other errors, comment out that code and leave a "TODO:" comment to come back to it.
   3. Repeat this process until all errors have been resolved or commented out.
10. Open the Visual Studio designer for any Forms or UserControls where Actipro controls were deleted and add the new control to the designer.
    1. Give the new controls the same name as the old controls.
    2. Attempt to restore any non-default property values.
    3. Attempt to restore any event handlers that were not commented out.
    4. It is recommended to ensure the solution will still compile after each individual Form or UserControl is updated.
11. Using one Form or UserControl at a time, begin to uncomment the previously commented code that had errors until all functionality is restored.  For commented out event handlers that need to be restored, it may be better to use the Visual Studio designer to add the event handler and then copy the old method body into the new method since some of the EventArgs implementations may have changed.
12. Search the rest of your solution for any TODO: comments and either restore or delete the related code until the solution is fully migrated.

For any code that has errors, you will have to try to resolve the error by looking at our documentation or extensive set of samples in the Sample Browser application.  Since you are attempting to migrate from a very old version of the controls, you will likely have several errors to address.  Our Sample Browser application has many examples of using SyntaxEditor and most of them are broken out into individual feature concepts.  If you are having trouble with bookmarks, for example, you should look at the Bookmarks sample and compare how that sample works and adjust your code accordingly.

The biggest migration hurdle involves any custom syntax languages that might have been developed. Since it appears you are using the pre-defined .NET Add-on, hopefully that does not apply to you.

Please reach out with any individual issues you may encounter during your migration and we'll do our best to point you in the right direction.

Thanks for your replies,I am also aware that .Network framework is backward Compataible.so i have changed the project from 4.0 framework to a 4.8.1 framework and I didn't even change any framework for Actiprosoftware it is an older version. after migrating the project while compiling the project it throws some errors in the actipro used projects like Could not load file or assembly. So I thought it was a version incompatible error.I started looking for the recent version of Actiprosoftware. Below I have mentioned the error for your reference.

Severity Code Description Project File Line Suppression State
Error 'Could not load file or assembly 'ActiproSoftware.SyntaxEditor.Net20, Version=4.0.246.0, Culture=neutral, PublicKeyToken=21a821480e210563' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)' 

Well, .NET Framework is backwards compatible "in theory", but little issues can always come up.  The assembly versions you are using are very old and obviously not officially supported on .NET Framework 4.8, so this is not something we have ever attempted.

You might want to try creating a new, blank .NET Framework 4.8 project and add the older assembly references to that project to see if you are able to compile in the most basic of scenario.

Just to make sure the assemblies are properly referenced/loaded, you may need to at least create an instance of the SyntaxEditor control after application startup.  If a clean project won't compile, you'll know you need updated Actipro assemblies for .NET Framework 4.8.  If it does compile, you may need to add a little more functionality one-by-one (like loading the .NET add-on) to see at which point it breaks.

Sure i will check all your point and will update you once it is solved