Completion lists are different between 2012.2 and 2013.1

SyntaxEditor for WPF Forum

Posted 7 years ago by Chris Shaw
Version: 13.1.0580
Platform: .NET 4.0
Environment: Windows 8 (64-bit)
Avatar

I installed version 2013.1 in place of 2012.2 (this is the *only* difference between two consecutive Change Sets in my repository), and the completion lists in the new version have lost items vis-a-vis the older version.  This won't work for me -- do you have any suggestions (either to help diagnose the problem, or to fix it?).

The language I'm using is C#.  The classes where I'm losing members are my own (List<T>, for instance, seems to work fine).  Again, no changes were made to my code base other than replacing the ActiPro .dlls.

[Modified 7 years ago]

Comments (4)

Posted 7 years ago by Chris Shaw
Avatar

Could this possibly be related to the following issue, reported late last month?  If so, should I change my code to accomodate it, or are you planning on a fix?

http://www.actiprosoftware.com/community/thread/20968/assembly-resolving-issue-in-20131580

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Chris,

We're not aware of any issues, and I assume you mean with the .NET Languages Add-on here. 

I'm not sure if the other thread you mentioned could trigger this.  It's possible and I would like to know if loading the Assembly manually and referencing that does fix the problem for you, as the other customer did.

If that doesn't help, what would be best is if you email our support address with a new simple sample project showing the completion list and give details on what you expect to see.  That way we can swap in 2012.2 and see what the difference is too, and debug from there.  Please reference this thread in your email and rename the .zip file extension so it doesn't get spam blocked.  Thanks!


Actipro Software Support

Posted 7 years ago by Chris Shaw
Avatar

After a bit of playing around, I think I can confirm that I was having the same issue as Nick:

This works, when I've manually loaded the Assembly (as he did):

 assemblyReference = project.AssemblyReferences.Add(Assembly a)

 

This doesn't (which is the way my code has been for some time):

assemblyReference = project.AssemblyReferences.AddFrom(String referencePath);

 

I didn't dive too deep, but like Nick, I found that it wasn't *every* .dll that wouldn't load, only some of them.  It may have been, as he says, only those that have dependencies on others, but I'm not sure about that.  In any case, using Add() rather than AddFrom() seems to have worked in my case.

Thanks,

--Chris

[BTW, if you're "not aware of any issues", does that mean that this is a feature?]

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Chris,

We never got a sample from the original poster so weren't sure if this was a problem.  Could you send over a simple sample (per our instructions above) that shows this issue, and some commented-out code showing the workaround working?  That would be helpful and we can debug it to make a decision on if we should revert back to the old code.


Actipro Software Support

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.