Dick,
We found an issue in the build support DLL for X#.
This caused the compiler not to run with the /shared compiler option.
We have fixed that now.
With 2.13 you should see faster builds inside VS, even when you build all projects.
Robert
Debugging horror
Debugging horror
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Debugging horror
Hello Robert,
Behaviour in VO: when I change something in a library, click Save but forget to recompile and directly run the main program, the change is included. It does still show the red dot however.
Behaviour in VS: when I change something in a library, click Save but forget to recompile and directly run the main program, the change is NOT included. VS does also not show anywhere that I changed something which needs recompilation.
I hope I am wrong but it works (or better not works) this way, I find this extremely poor. Even when checking all Build checkboxes would work faster now, I saw that unchecking all makes starting almost as fast as in VO but in a way I can't risk that as I may be testing code from which parts won't work as it was never recompiled.
Dick
This is great to know, but is my observation correct that VS has not even a mechanism to detect which libraries changed and need to be recompiled?robert post=23286 userid=253 wrote:With 2.13 you should see faster builds inside VS, even when you build all projects.
Behaviour in VO: when I change something in a library, click Save but forget to recompile and directly run the main program, the change is included. It does still show the red dot however.
Behaviour in VS: when I change something in a library, click Save but forget to recompile and directly run the main program, the change is NOT included. VS does also not show anywhere that I changed something which needs recompilation.
I hope I am wrong but it works (or better not works) this way, I find this extremely poor. Even when checking all Build checkboxes would work faster now, I saw that unchecking all makes starting almost as fast as in VO but in a way I can't risk that as I may be testing code from which parts won't work as it was never recompiled.
Dick
Debugging horror
Can anyone either confirm my assumption, see previous message #23289) that VS has no means to detect which libs should be compiled?
Or, better, tell my that I am wrong (and what I should do to avoid to check all libs to build)
Dick
Or, better, tell my that I am wrong (and what I should do to avoid to check all libs to build)
Dick
Debugging horror
Hi Dick,
When you compile a certain library, then VS (MSBuild actually), assumes by default that all other libraries that have a reference to it, need to also be rebuilt. Libraries that do not reference this library do not get rebuilt, unless you specifically ask to do so, by using REbuild.
Indeed, because there's no repo as in VO, VS can't tell if a change in a library does actually make it necessary to rebuild its dependent ones, that's the downside. The upside is that there are no repo corruptions in VS and other .Net IDEs... Only in the last couple months, I have had so many repo corruptions and VO crashes with the "Sorry" message while testing people's apps in VO first, before porting them to X#, which made me remember how glad I am that I hadn't have to deal anymore with this in the last 10 years or so...
.
When you compile a certain library, then VS (MSBuild actually), assumes by default that all other libraries that have a reference to it, need to also be rebuilt. Libraries that do not reference this library do not get rebuilt, unless you specifically ask to do so, by using REbuild.
Indeed, because there's no repo as in VO, VS can't tell if a change in a library does actually make it necessary to rebuild its dependent ones, that's the downside. The upside is that there are no repo corruptions in VS and other .Net IDEs... Only in the last couple months, I have had so many repo corruptions and VO crashes with the "Sorry" message while testing people's apps in VO first, before porting them to X#, which made me remember how glad I am that I hadn't have to deal anymore with this in the last 10 years or so...
.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Debugging horror
Hello Chris,
Thanks for confirming. I haven't seen a corruption in my repo for years but I see the "Sorry" message regularly. That is irritating but fortunately VO is very fast and up and running again in a few seconds. If I would sum all these few seconds it would be only a fraction of the time I have spent to solve the VS problems I had in the same period. Far less than VO's "Sorry" but far more time consuming and often hard to solve, so much more nerving.
I find that the more I work in VS and .Net, the more disadvantages against VO I find. Advantages are there too but they rare and often small.
I am not sure what you mean with "MSBuild assumes by default that all other libraries that have a reference to it, need to also be rebuilt.".
What do you mean by "assume"? I found that after I changed something, with no "Build" checkboxes checked, nothing was compiled and the previous code was executed. But even if it was, if all referenced libraries would recompile after a tiny change in 1 of them, that would not be very helpful either.
Dick
Thanks for confirming. I haven't seen a corruption in my repo for years but I see the "Sorry" message regularly. That is irritating but fortunately VO is very fast and up and running again in a few seconds. If I would sum all these few seconds it would be only a fraction of the time I have spent to solve the VS problems I had in the same period. Far less than VO's "Sorry" but far more time consuming and often hard to solve, so much more nerving.
I find that the more I work in VS and .Net, the more disadvantages against VO I find. Advantages are there too but they rare and often small.
I am not sure what you mean with "MSBuild assumes by default that all other libraries that have a reference to it, need to also be rebuilt.".
What do you mean by "assume"? I found that after I changed something, with no "Build" checkboxes checked, nothing was compiled and the previous code was executed. But even if it was, if all referenced libraries would recompile after a tiny change in 1 of them, that would not be very helpful either.
Dick
Debugging horror
Hi Dick,
By default, all those checkboxes are enabled. When you disable them, indeed Build does not compile the dependent projects automatically anymore.
By default, all those checkboxes are enabled. When you disable them, indeed Build does not compile the dependent projects automatically anymore.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Debugging horror
I didn't even have to wait 1 day before we had another VS issue which costed us more than 1 year VO's "sorry" crashes.
Frank was compiling some small code changes in our X# project but it took extremely long. Also when retrying. We eventually found this great helpful Microsoft Build message:
Error MSB4181 The "Xsc" task returned false but did not log an error. Kleijn C:XSharpMsBuildXSharp.targets 209
Frank cleaned the solution, tried a rebuild. No succes. After the usual VS waste of time Frank reset his computer and then he could rebuild again.
I think I can easily say that Robert eventually solved VO's repo issues, only regular (3-4 times a week) but easy and quick to solve crashes remain. But Microsoft has never solved (and will never solve) it's crappy software which errors will always cost substantial time to overcome, invariably after trying dozens of different suggested tricks due to the fact that Microsoft has never been able to create error messages which make any sense, let alone help to solve an issue.
Which, I think, is clearly illustrated with the above error which appeared truly out of the blue.
Dick
Frank was compiling some small code changes in our X# project but it took extremely long. Also when retrying. We eventually found this great helpful Microsoft Build message:
Error MSB4181 The "Xsc" task returned false but did not log an error. Kleijn C:XSharpMsBuildXSharp.targets 209
Frank cleaned the solution, tried a rebuild. No succes. After the usual VS waste of time Frank reset his computer and then he could rebuild again.
I think I can easily say that Robert eventually solved VO's repo issues, only regular (3-4 times a week) but easy and quick to solve crashes remain. But Microsoft has never solved (and will never solve) it's crappy software which errors will always cost substantial time to overcome, invariably after trying dozens of different suggested tricks due to the fact that Microsoft has never been able to create error messages which make any sense, let alone help to solve an issue.
Which, I think, is clearly illustrated with the above error which appeared truly out of the blue.
Dick
Debugging horror
Dick,
I would love to blame Microsoft for all errors that occur, but in this case the error is probably in our code.
XSharp.targets is our file and line 209 is the location where the xsc.exe process is started.
I wish I could say more about the cause of the error. I need more information for that.
Robert
I would love to blame Microsoft for all errors that occur, but in this case the error is probably in our code.
XSharp.targets is our file and line 209 is the location where the xsc.exe process is started.
I wish I could say more about the cause of the error. I need more information for that.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Debugging horror
Hello Robert,
I think we can safely blame Microsoft. It appeared suddenly with no unusual program change and it disappeared eventually after restarting the Pc, once again cleaning the code and rebuilding it. I have seen these situations earlier and the line where it went wrong seems randomly picked by VS. If it was really causing the problem it would have started by a recognizable action and also persist, not disappear after restarting the Pc.
Dick
I think we can safely blame Microsoft. It appeared suddenly with no unusual program change and it disappeared eventually after restarting the Pc, once again cleaning the code and rebuilding it. I have seen these situations earlier and the line where it went wrong seems randomly picked by VS. If it was really causing the problem it would have started by a recognizable action and also persist, not disappear after restarting the Pc.
Dick