Hi I just recently started learning about using the windows form application for C++. I am using Visual Studio 2010 and I have came across this problem. For instance, I am trying to read and write to a text file. Many guides suggest using StreamWriter^ and using namespace System::IO; to read/write to a file.

My question is why can't I use #include <fstream> to read/write to files like in console c++? I have tried using fstream in the windows form application and it works. Both the compiled and debug versions of the program works. Please could somebody explain to me why this is and if I should still be doing this. Thank you.

Recommended Answers

All 22 Replies

When you're using .net for a windows form project both the .net library and the C++ standard library are available. For many people, using the .net library is more intuitive. Also if at some point you branch out and start using other .net languages being used to the .net library will help.

Thank you kindly for your reply. I have found a problem. For computers that does not have the Microsoft Visual Studio 2010 installed, the windows form program will simply not run on them until I removed libraries such as #include <iostream> and #include <fstream>.

Why is this so? How come I could execute the executable and debug version on my PC but on other PC it would not work?

When you copile for debug the compiler uses the debug version of windows dlls instead of the standard non-debug version. So if you move your debug program to a compiler that doesn't have Visual Studio installed the os will not contain the debug version of the DLLs. You have to re-compile programs for Release mode before copying them to other computers.

I have set the compiler to "release mode" and it still does not work. However if I remove #include <fstream> and #include <iostream> from the header at the top then it would run on the other computer. I read somewhere that windows form was CLR or managed code and this was the reason to use StreamWriter^. However, how come it was possible to use such C++ instructions such as ofstream file; and such in a windows form application?

However, how come it was possible to use such C++ instructions such as ofstream file; and such in a windows form application?

Because C++/CLI would be far less useful and attractive if you were denied any of the standard C++ libraries in managed code.

Is the version of MS-Windows the same on both computers? What error message(s) do you get when you try to run the program on the computer that does not have the compiler installed? I'm thinking you might also have to install some of the "redistributables" files. Look in the compiler's install directory, there should be a folder named redist. On my computer it's here: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist. If you can't find this then I think you can download the files from Microsoft site.

1) The program would display an error that says test.exe has stopped working. The error list when clicked on the "View problem details" is:

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: test.exe
  Application Version:
  Application Timestamp:    5293b38f
  Fault Module Name:    KERNELBASE.dll
  Fault Module Version: 6.1.7601.18229
  Fault Module Timestamp:   51fb1116
  Exception Code:   e0434352
  Exception Offset: 0000c41f
  OS Version:   6.1.7601.
  Locale ID:    1033
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:

If the online privacy statement is not available, please read our privacy statement offline:

2) Both compiler PC and noncompiler PC have the same version of Windows.

3) If I remove #include <fstream> from the form1.h file then it would run on the non-compiler PC.

Ancient Dragon please refer to this post you made a year earlier. The user is trying to do a similar task to what I am doing. Except my program could read/write correctly using #include <fstream>. I'm not sure why the compiled program would only run on the system with VS2010 installed and not on a nonVS2010. Thank you thus far for your assistance.

Study some of these links on how to mix managed and unmanaged code.

Thank you for your fast response.

Before I go on studying these links, ultimately would it be possible to use such libraries as #include <fstream> inside Windows forms? Somehow it does work on a VS2010 computer and not a VS2010 computer so I'm guess it must be possible.

You need to put pragmas around unmanaged code. The only way to find out if it will fix your problem is for you to test it on the computer that does not have visual studio.

[edit]I don't have VS 2010, but VS 2013 compiles and works ok without the pragmas on the computer that has vs installed, just as you reported. I don't have a computer without VS so I can't test that part of your problem.

I tested on a computer that does not have VS installed and it worked without a problem after installing the Microsoft redistributable DLLs.

#include "stdafx.h"
#include <fstream>
#include <iostream>
using namespace System;

int main(array<System::String ^> ^args)
    std::ofstream out("Text.txt");
    if (!out.is_open())
        std::cout << "Cannot open file\n";
        return 1;
    out << "Hello World From fstream\n";
    Console::WriteLine(L"Hello World");
    return 0;

Thank you so much Ancient Dragon for your continued assistance. I am really grateful to see that you have went the extra mile to test on a nonVS computer.

When you say "Microsoft redistributable DLLs" you mean the dll files inside C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x64 for the Win64 system right?

Because inside the x64 folder I see it contains five other folders named:

and inside those folders contains dll files. I'm not sure what we would copy these dlls to in order to install them on the nonVS computer.

Yes that is the right place. You need at least the DLLs in "Microsoft.VC100.CRT". The others are for specific types of programs, such as MFC and ATL.

Are we suppose to place those dlls into the same folder as the executable? I have tried the dlls inside the Microsoft.VC100.CRT only and all the dlls and the executable still does not run.

I put them in the same folder as the executable. Can you post the entire program you are tring to run and I will try to make it run on my computers? If not, can you replicate the problem with the code I posted earlier?

Yes surely. Here is the program:


#pragma once
#include <iostream>
#include <fstream>

namespace Project {

    using namespace System;
    using namespace System::ComponentModel;
    using namespace System::Collections;
    using namespace System::Windows::Forms;
    using namespace System::Data;
    using namespace System::Drawing;
    using namespace System::Threading;
    using namespace std;

    /// <summary>
    /// Summary for Form1
    /// </summary>
    public ref class Form1 : public System::Windows::Forms::Form
            //TODO: Add the constructor code here

        /// <summary>
        /// Clean up any resources being used.
        /// </summary>
            if (components)
                delete components;
    private: System::Windows::Forms::Button^  button1;

        /// <summary>
        /// Required designer variable.
        /// </summary>
        System::ComponentModel::Container ^components;

#pragma region Windows Form Designer generated code
        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        void InitializeComponent(void)
            this->button1 = (gcnew System::Windows::Forms::Button());
            // button1
            this->button1->Location = System::Drawing::Point(111, 140);
            this->button1->Name = L"button1";
            this->button1->Size = System::Drawing::Size(75, 23);
            this->button1->TabIndex = 0;
            this->button1->Text = L"button1";
            this->button1->UseVisualStyleBackColor = true;
            this->button1->Click += gcnew System::EventHandler(this, &Form1::button1_Click);
            // Form1
            this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);
            this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;
            this->ClientSize = System::Drawing::Size(284, 262);
            this->Name = L"Form1";
            this->Text = L"Form1";

#pragma endregion
    private: System::Void button1_Click(System::Object^  sender, System::EventArgs^  e) {
                 ofstream outFile;
                 outFile << "Hello World";

*All other files such as Project.cpp, stdafx.cpp, and ect. are unmodified.

This is a C++ Windows Forms Applications. It contains one button and clicking that button would create a text file named text.txt with the contents Hello World.

Please try to see if you can get the same result.

I compiled with VS 2012 (not VS 2013) and ran ok on the computer that doesn't have vs installed. The only change I made to the file you posted was added using std::ofstream; after the two includes at the top of the file. I used the File1.cpp my compiler generated instead of the one you posted, then added the few lines that you posted.

There are several sets of redist DLLs, I used the ones in redist/x64 folder because the target computer has 64-bit version of Windows 7. The program itself is compiled as 32-bit program.

First off I wanted to say thank you Ancient Dragon for being so persistent in helping me resolve this problem. I did try your method of adding using std::ofstream; after the two includes at the top and the program still didnt work.

However, when I used the two dll files msvcp100.dll and msvcr100.dll from the x86 folder it worked. My head is now spinning... how could this be? Both my VC2010 computer and nonVC2010 computers are Win7 x64. This is truly a strange outcome.

VS++ defaults to 32-bit compiles. If you want to compile for 64-bit you have to use the configuration manager to change it (the text box that says win32).

Oh I see it. Thank you for your help, my problem is now resolved.

Although I have one last question. I was searching around in this forum for people having problems similar to mine and came across these these two posts: Post1 and Post2. In those two posts I could see you saying CLR/C++ and how iostream cannot be used with them. Isn't my program similar to theirs?

Yes it is similar. At one time CLR/C++ didn't support fstreams, but obviously that is no longer the case. I also may have just been incorrect when I said that (wouldn't be the first time :) )

Ah I see. I was just confused at that part. Well thank you for your help. Have a good day.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.