The point is "stack semantics", not "stack allocation". The memory for
the object is indeed allocated from GC heap, but it is (mostly)
irrelevant here.

Who's talking about stack allocated reference classes,  I said "assign it to
a stack allocated variable" right?
I know ref. classes aren't stack allocated, they have stack semantics.

For the compiler there's a difference between:
FileStream fs = fi->OpenRead();
and
FileStream fs(...);
The first is an assignment of a "stack allocated variable", with stack
semantics, to a value with "reference" semantics (of type FileStream),
returned by a (C#) function call. This is something that the current C++
compiler can't handled, why he's insisting on a copy constructor is beyond
me, ref class can't have copy constructors.
The latter is a constructor call, that upon return (note: nothing is
returned from the constructor!!!), initializes a stack allocated variable
with stack semantics. This initialization is completely handled by the C++
compiler.

Herewith a simple sample that illustrates the issue:

// C#
 public class Tester
{
   public Test GetTest()
   {
     Test t = new Test();
     return t;
   }
}

 public class Test
 {...
 }
}

// C++
Tester t;
Test tt = t.GetTest();

Willy.

Something like this would be nice, but it can't be done the way you're
trying to do it.

I think the code above would expand to

FileStream^ fs = gcnew FileStream(fi.OpenRead());
[...]

and there is no such copy constructor in FileStream (and even if there
was one, you wouldn't want to make a copy in this case).

There is such a thing as copy c'tor and assignment operator in C++/CLI.
Because what if you want to make a copy? You could always define a
static member (class method) name CopyMe, but C++/CLI was designed to be
as conforming with C++ as possible. The stack syntax with ref classes
has to work like stack objects in native C++, otherwise you're inventing
a new language that has nothing to do with C++. Exactly that happened
with the old MC++, where the destructor syntax was used for the
finalizer. Such a radical change has disadvantages, because C++
programmers have certain expectations about the language, such as the
copy c'tor syntax, even if it's implemented in the underlying .NET layer
differently.

What you're asking for is

cli::auto_ptr<FileStream> fs(fi.OpenRead());

which may or may not exist. If it doesn't, you can try to write your
own. It would have a little bit of an overhead, but only a couple of
extra CLI instructions.

Here's an auto pointer template that I wrote, although it has a
completely different purpose (to store unmanaged objects inside a
managed wrapper):

#pragma once

template <class T>
public ref class CliScopedPtr
{
   typedef CliScopedPtr<T> this_type;

public:
   CliScopedPtr()
    : ptr(nullptr)
   {
   }

   explicit CliScopedPtr(T* p)
    : ptr(p)
   {
   }

   ~CliScopedPtr()
   {
      delete ptr;
   }

   T* get()
   {
      return ptr;
   }
   
   T& operator*()
   {
      return *ptr;
   }

   T* operator->()
   {
      return ptr;
   }

   bool assigned()
   {
      return ptr != nullptr;
   }

   void swap(CliScopedPtr% other)
   {
      T* tmp = other.ptr;
      other.ptr = ptr;
      ptr = tmp;
   }

   void swap(CliScopedPtr^ other)
   {
      T* tmp = other->ptr;
      other->ptr = ptr;
      ptr = tmp;
   }

   void reset()
   {
      this_type().swap(this);
   }
   
   void reset(T* p)
   {
      this_type(p).swap(this);
   }

private:
   T* ptr;
   CliScopedPtr(CliScopedPtr%); // disabled
   CliScopedPtr% operator=(CliScopedPtr%); // disabled
};

Credit goes to boost::scoped_ptr for the idea.

Example:

class Unmanaged { };

CliScopedPtr<Unmanaged> ptr(new Unmanaged);

Tom