none
An attempt to emulate Mathematica for mathematics students aged 12-18. RRS feed

  • Question

  • I stopped building my program because VS 2017 only build successful debug builds and none release build. I just started using Visual Studio Community 2019. My last successful debug build was 32-bits. The same code for 64-bits generated only repeated C1083 errors for every include of my basic include file. And even with a renewed license! I might have to stop trying to develop a successful release build? I will be grateful for any help your community might provide.

    I am Ton Epskamp at a.epskamp@ziggo.nl.

    Wednesday, January 8, 2020 7:08 PM

Answers

  • And what about the executable paths for the Visual C++ environment?

    If you change this in such a way that cl.exe is no longer in the list of paths given you will get the exact error you are describing.

    This can also be verified by creating a new project and seeing if you can build something there. If you can't then check the property sheets. You most likely didn't override paths and inherit settings properly.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Marked as answer by Ton1 Epskamp Sunday, January 19, 2020 6:14 PM
    Sunday, January 19, 2020 2:43 AM

All replies

  • Hi Ton Epskamp,

    Welcome to MSDN forum.

    According to your description, it seems that you don't configure same environment for x64 and release mode in VS. You could right-click project, then set configuration to "All configuration" and platform to "All Platforms".

    After that you could re-configure your project, then re-build the project to check if it could work.

    Looking forward to your feedback.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Thursday, January 9, 2020 3:02 AM
  • Hello Dylan,

    Thank you very much for your fast reaction. I never changed "Configuration" to "All configurations" and never "Platform" to "All platforms". But now I did as you suggested! I started with Win32 and got a successful build. Then I changed to x64 leaving Debug unchanged and got again for every of my source code files with identical #include's the same C1083. I had this happening before a few times but renewing my license corrected always these C1083 errors. And I got my 64-bits debug executables built. I even got both release executables built but none of them complied my inbuilt test of solving correctly all my 6,000 exercises. Both my debug builds do comply this same test always!

    It seems a very pity of course that this time renewing my license didn't make any difference:

    - So Microsoft doesn't prevent me from building my 32-bits debug executables but

    - Microsoft does prevent me from building my 64-bits debug executables by issuing C1038 errors.

    But my code remained unchanged and in my project I only had to adapt MACHINE:X86 to MACHINE:X64! Perhaps Microsoft's patience might have been exhausted?

    Ton Epskamp at a.epskamp@ziggo.nl.

    Thursday, January 9, 2020 11:18 PM
  • Hi Ton Epskamp,

    Thank you for feedback.

    Did you include your header file under All Configurations and All platforms? From your description, it seems that you didn't configur the same environment for X64 with debug or release mode. 

    Please refer this image:

    Any feedback will be expected.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Friday, January 10, 2020 8:28 AM
  • Hi Dylan,

    I developed 4 educational mathematical programs in Visual Studio during decades of years. All my debug builds are working perfectly but all of my release builds fail my own test of solving correctly 6,000 mathematical exercises. I am now using Visual Studio Community to create for all of my 4 programs both debug and release builds in Windows 10. That took some time of course! In this process of rebuilding I made some corrections so I restarted the process once more to process all of these corrections. So I was already able to build both 32/64-bits debug and release executables for most of my 4 projects. But now it seems that Visual Studio Community will only permit me to create 32-bits debug and no 64-bits debug builds. Because I don't understand anything of it I start to believe that Visual Studio Community or possibly Microsoft might be preventing me from succeeding in both 32 and 64-bits. There is no difference in the code between 32-bits and 64-bits except in the most important include file where I have

    - #define x64 // for a 64-bits project and

    - //#define x64 // for a 32-bits project.

    I am using a similar "(//)#define release" in my code because when coding I need to know about being in a debug or release build. I CAN'T IMAGINE THIS MAKING ANY DIFFERENCE IN BOTH BUILDING A 32 OR 64-BITS AND A DEBUG OR RELEASE BUILD!

    I still have a successful 32-bits debug build and a 64-bits debug build generating error C1083 for all of my source code files. And I still remain afraid the C1083 might be due to omitting an update of my license! But the day before yesterday I made successfully this update.

    It is a pity me not being a genius! Being a genius I wouldn't be bothering you anymore: SORRY!

    With all regards from Ton Epskamp at a.epskamp@ziggo.nl.


    • Edited by Ton1 Epskamp Friday, January 10, 2020 3:50 PM a writing error
    Friday, January 10, 2020 3:48 PM
  • Hi Dylan,

    I am reporting not only to you but also to the complete community: I restarted my program in Visual Studio Community 2017 because in Visual Studio Community 2019 I got that terrible TRK0005 error about not finding CL.EXE. It was a very pity that Visual Studio Community 2017 produced exactly this same error. So now I will be completely stuck in the middle of nowhere. I am afraid my only conclusion can be that Microsoft is wanting to get rid of me! I certainly don't know why and I remain wondering if there might be more developers they want to get rid of too? Or will I remain the only one? If you experienced this same problem how did you recover from it, please tell me! If I ever conflicted with Microsoft why didn't they notice me about it? It would never be too late! So ...?

    I am Ton Epskamp at a.epskamp@ziggo.nl.

    Saturday, January 18, 2020 10:26 AM
  • Silly question, did you actually install the C++ toolchain?

    For the Visual Studio 2019 installer, it is the same with the 2017 installer too, the C++ compiler is listed under optional components:

    Notice the very first optional component is the C++ build tools? This is the package that include cl.exe, link.exe and most of the other vital tools that you need to actually build things. The second optional component is the Windows 10 SDK which includes rc.exe, mc.exe, the CRT and other vital tools that you need to build things.

    So you may be thinking, if these are vital then why are they under optional components? Well, further down the list:

    You can not only find CLANG tools for Visual Studio but the Visual Studio 2017 and 2015 compilers. So any one of these four must be installed. You should also see that there are multiple versions of the Windows 10 SDK available, so again any one of these is required. So because of this it is awkward because at least one is required but you can choose to install them all if you want. What's more, if you have an older version of Visual Studio installed, like 2013, then Visual Studio 2019 doesn't even need any of these installed since it can use the 2013 build tools too.

    If you have at least one compiler and one SDK installed but you are still having this error then one of two things have happened.

    1) The platform toolset has been improperly set.

    The MSVC toolset version option was only really added recently in the properties, but it has been settable in the .vcxproj file for a while.

    2) The installation failed but didn't notify you about this. This can happen and doing a repair install is the only way to fix it.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Saturday, January 18, 2020 12:40 PM
  • Hello Darran,

    I finished building all 4 of my projects a month ago without any difficulties. In this process I had to restart again at the first of my projects. And I left everything unchanged: not completely my code but my projects and also Visual Studio Community 2019. Because of your answer I reloaded today only Visual Studio Community 2019. On the status bar I could see Visual Studio Community 2019 was loaded instantaneously. But I never loaded separately a toolchain. If I would have to start doing this now I have to admit that I at the moment wouldn't know how to achieve this because I only see possibilities to download Visual Studio Community 2019 and can't detect any way of downloading this toolchain separately. And I have never missed them until now. And besides of this when downloading Visual Studio Community 2019 I did mark always the necessary tools. So I don't know what went wrong but building or compiling is generating certainly TRK0005 at the moment! I have cl.exe in C:\Program Files (x86)\Microsoft Visual Studio\2019\VC\Tools\MSVC\14.24.28314\bin\Host86 or Host64\x64 or x86\cl.exe. And that is not different from a year ago! That is the reason for the desperate character of my last submitting on the thread started long ago by me: "An attempt to emulate Mathematica for mathematics students aged 12-18". Today I tried at least 5 times but every time I got this same TRK0005! I have never before encountered this same TRK0005 error! As far as I detected tracker.exe isn't from Microsoft but from elsewhere.

    Thanks again for your patience!

    Saturday, January 18, 2020 8:11 PM
  • And what about the executable paths for the Visual C++ environment?

    If you change this in such a way that cl.exe is no longer in the list of paths given you will get the exact error you are describing.

    This can also be verified by creating a new project and seeing if you can build something there. If you can't then check the property sheets. You most likely didn't override paths and inherit settings properly.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Marked as answer by Ton1 Epskamp Sunday, January 19, 2020 6:14 PM
    Sunday, January 19, 2020 2:43 AM
  • With these type of problems it is almost always down to something not setup right in VS.

    On a few occasions I have blamed VS only to find I dont have something included in the install or an SDK has changed or the project just needs a clean and rebuild.

    I would be comparing project settings in release and debug modes to start with.


    n.Wright

    • Marked as answer by Ton1 Epskamp Sunday, January 19, 2020 6:15 PM
    • Unmarked as answer by Ton1 Epskamp Sunday, January 19, 2020 6:15 PM
    Sunday, January 19, 2020 10:12 AM
  • Hello Darran, Dylan and Nigel,

    I used both your recommendations and eventually my efforts succeeded in restarting properly my Visual Studio Community 2019. Most important was both Darran's and Nigel's comment to correct the executable path in the property pages of my project. I understood this as a path to my own executables in stead of Visual Studio's. So I didn't look well enough at the text down on the same page. So I started to write down the appropriate path to cl.exe in a few subdirectories of C:\Microsoft Visual Studio\... While doing this Visual Studio changed this in "<different options>". After that compiling and building went smooth again. A few remarks for everybody well understanding:

    - I am working with a few community versions for nearly a year and I never had this same <different options>.

    - In that past year I never had this same difficulty.

    - I don't claim to be the most clever developer so I do apologize!

    I do wish to thank you all very much for both your patience and your help. From now on I hope to continue and finish all of my projects. But a special "thank you" should be for Darran: I doubt if you remember a former problem when all of my debug builds were OK but none of my release builds did comply my inbuilt test of solving all of my 6,000 mathematical exercises included in all of my projects. But now for the first time my first and most basic program was complying this test in both 32 and 64-bits and also in both release and debug builds. I even myself don't understand it but all of these four builds passed this test, thank you very much, Darran!

    I am Ton Epskamp at a.epskamp@ziggo.nl




    Sunday, January 19, 2020 6:55 PM
  • Hello Darran,

    You not only helped me getting my Visual Studio Community 2019 working again but you simultaneously solved my 1½ year older problem with my release builds not complying my test of solving all of 6,000 mathematical exercises built in the executables of all my projects. Before only my debug builds passed this test! However only one problem is left to solve: I don't understand how this has happened:

    1. All my executables have grown much larger.

    2. The difference in size of debug and release builds was always ±300KB and now applies for the 64-bits builds that they equal in size and for the 32-bits builds it became 157KB: BOTH MIRACULOUSLY SMALLER!

    You explained me the reason for the difference of a debug and release build: in a debug build will the compiler zero initialize all not properly initialized local variables whereas  a  release build omitted this same step. I bought in 2013 Microfocus's Devpartner but that didn't solve  my problem! I wouldn't like to grow a compiler builder but could you explain it to me or indicate a way to understand it better?

    Thank you very much again!

    I am Ton Epskamp at a.epskamp@ziggo.nl.

     
    Tuesday, January 21, 2020 10:13 AM
  • Dear friends,

    I started rebuilding all of my projects and everything seems Ok but for one exception: I have a fully organized help file for all of my 4 projects. But I did create it a very long time ago and still in 32-bits Windows. So now apparently my help file is working fine when in 32-bits but make all of my projects hung in 64-bits! In all of them there will be an unhandled exception! I used the Html Workshop to create it but I seem unable to get things working in 64-bits Windows. WHAT DO I FORGET OR WRONG? DO I HAVE TO REBUILD IT BY USING THE Html Workshop AGAIN? Again I remain thanking all of you for your help! It is a pity I remain in need of your help still and again! I have included htmlhelp.lib in my link but apparently that does seem enough for 32-bits but not for 64-bits!

    I am Ton Epskamp at a.epskamp@ziggo.nl.

    Thursday, January 23, 2020 11:52 AM