TOPIC:

I am using Visual Studio 2017 community version to test out X#. Ever since we converted out VO application to X#, Visual Studio randomly crashed or stop responding. While scrolling or clicking within the prg file, VS sometime stop responding. Often time it return to normal. Other time it restart VS.

Also, I sometime get "assertion failed" error when I'm compiling or running our converted application. A simple restart of VS would fix it. It doesn't happen all the time.

I didn't experience these issues when I created my test X# application from scratch using Core dialect. Of course that application was small. This is only occurring for the converted VO application using VO dialect.

Any idea on how to fix these issues or minimize it?

Thanks,

Boonnam

Here is additional information after this is consistently happening after I posted this message.

Take this line:
SELF:oNetUsrs:LOGIN := Today()

I want to change it to SELF:oNetUsrs:FIELDPUT(#LOGIN, Today()).

After clicking right after the 2nd colon, VS would pause (Not Responding). Most of the time, it would be OK. Then I would type "FIELDPUT(#". As soon as I typed the "#", VS would pause. This would occur about half of the time. About 20 percent of the time, VS would hang and restart, and I would lose all the changes if I didn't save. I think this related to intellisense.

Hi Boonnam,

Thanks for the additional info, this should help finding the problem. I could not reproduce this here though for now.

Have you installed the latest Update 1 build? I suspect the problem has to do with displaying the info tooltip when you put the mouse after the colon and the guys have fixed some related issues after the first general release, in the newer Update 1.

If the problem still happens with Update 1, could you please send us a repro sample, if you can now consistently reproduce this issue?

Chris

Boonnam,

Without seeing your code it is difficult to give you a good hint about what might be causing the problems.
Some questions:
- How did you declare the oNetUsrs field or property ?
- Which version are you using ?
- Which 3rd party or external assemblies are you referencing ?

Robert

Robert and Chris,

I installed update 1 when it came out. The only 3rd party assemblies and references we are using are the Vulcan DLLs. Right now we are focusing on getting this application to run almost as is.

oNetUsrs is originally declared as Object. Yesterday, I noticed that on my machine it is not opening the index, so I tried declaring is as NetServer, which is DBServer. The index is still not being opened. I didn't mean to imply that it is happening only for oNetUsrs. It was just an example.

After VS restarts, the issue will not happen right away. How do I turn off the tooltip? I'm willing to try that. Thanks.

This is Sukhoon Ko and I work with Boonnam. I was having the same issue(VS2017 hanging and crashing).
I checked the task manager when it was hanging and found out that VS2017 was taking 1.7G memory and XSCompiler.exe was taking 3.6g memory. I closed visual studio 2017 and XSCompiler was still running and taking little less than 1gb memory. It looks like XSComplier never closes even after the build is over and running in background.

Guys,

It is normal that the compiler stays in memory after build, this happens in order to speed up compilation so that it doesn't load every time you compile, again and again. You can control this with the option "Use Shared Compiler" in the Build page of the project properties, if you set it to false, the compiler will not stay in memory after compiling.

The problem with VS crashing or not responding is of course a bug, but we need a reproducible sample to be able to find and fix it. A lot of people have sent us their code in the past in order to debug such issues, usually it's the only way to do this. If you can't send your complete solution, maybe you can reproduce the problem also in smaller projects? If yes, please send those to us so we have something to debug the issue. You can send it directly to me at chris (at) xsharp. eu

Chris

Guys,

To add to what Chris said:
we did not invent this. the VB and C# compiler do this as well.
We inherited the behaviour from Roslyn.
After compiling C# or VB code you will see that the VBCSCompiler.Exe remains in memory.

Robert

Sukhoon, Boonam.

Fabrice and I have made some changes to the VS intellisense. That will probably solve the hanging.
We will most likely release a patch to our FOX subscribers end of next week.

Robert

I just posted some issues in the NG, one of them a sudden VS 2017 error:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9):
error MC1000: Unknown build error, 'Exception of type
'System.OutOfMemoryException' was thrown.'

(solved by a restart of VS 2017)

and this one, in my VS 2015, not solved with a restart. No idea how to solve it anyway.

VS 2017 could be the problem but the 2ne error is VS 2015. Basically I can not run the project anymore.

Severity Code Description Project File Line
Suppression State
Error XS9015 No explicit constructor chaining; generating implicit
call to super constructor. JelleTestApp
D:\XSharpProjects\TestApp\WPFWindow1.xaml.prg 21

Dick,

XS9015 No explicit constructor chaining; generating implicit
call to super constructor. JelleTestApp

This is a WARNING, and I assume you have "Warnings as Errors" activated.
Add a call to SUPER() in the constructor of JelleTestApp and the problem should be gone.
I do not know why you are getting "Out of Memory" errors in VS2017. I need to see the project to comment on that.


Robert

Hello Robert,

You're right, warnings as errors & the super() call solves it.
What puzzles me: where does this suddenly come from? There was no super() in it before (just a standard generated X# project) and it worked without that error.

There's also the puzzle of the failing seek in a dbserver (see NG). It was solved by recreating the project and copying the source 1:1 to the new project. It puzzled me why I could open the dbf, perform a goto and show content, but the seek failed. With 1:1 the same code and using the same dbf in the new project it worked. If there's some reference missing or faulty one would expect the whole dbf handling to fail, not only the seek?

About the memory error: this is no doubt some VS 2017 problem and as written, it was solved after a VS restart.

Hi Dick,

You got this warning in a new class you created, isn't it? So the compiler started reporting this when you created a constructor that did not call super(). As I said in my reply to you in the ng, it is very easy if you want to disable the warning if you want, by adding it in the Suppress Specific Warnings project property.

Regarding the dbf index, I suspect in one app you were using RDDSetDefault() and in the other you didn't, is that correct? If not, we need to see the code that didn't work properly to say what was the problem.

Chris

Hello Chris,

Thank you for replying also on the NG. Although I prefer the NG, and you are watching it as well as the forum, I have to "face reality" which is that I am about the only one using the NG. Which means that there's a better chance that others read a question here than in the NG, so -reluctantly- I will move future questions to the forum too. I'll deal with Office 2016 (although when possible I use Word/Excel 2003 which is way faster and has less steps in almost everything), with VS instead of VO (further explanation unnecessary ) so dealing with a forum instead of a ng isn't that much more of a burden.

If there's any chance to forward messages to the NG then it would be ideal. Even if it's one way (posting here but able to read & keep in a NG).

For now I'll react in the Ng on all your replies because it's partly off topic in this posting anyhow...