VC .Net not mature?

[The unProfessional]

To the VC .Net'ers out there...

I noticed alot of strange behavior in the way VC .Net apps behave in the
IDE. It's a bit odd, so maybe people have workarounds. I'm worried to
devote my project to the managed/unmanaged heuristic because these early
issues make me feel VC .net just isn't mainstream (or complete) enough yet
to depend on.

Anyway, one of the things is the code formatting. When adding event
handlers and such, the code is formatted like so...

public void Func (...)
{

}

with the brackets strangely indented. Also, the functions are often jammed
right up against another, and even sometimes, the bracket scope gets messed
up.

public void Func1 (...)
{

public void Func2 (...)
{

}
}

... automatically, by the IDE... = BAD!

This is contrary to the way IDE-generated code behaves in purely managed
apps (C# or VB.net), hence my confusion about the stability of VC .net.

Also... why do event handlers automatically get dumped in the .h file?
Seems strange... C++ projects almost always, at least if style is an issue,
separate implementation from declaration (Cpp files), both for organization
and compilation issues. However, VC .Net seems to ignore this convention
and throw everything into the header files. Kind of annoying


Anyway, I guess the real question is, is VC .Net a good idea for a large
project? Is it fairly straightforward to combine alot of previously written
unmanaged code with managed interfaces and windows forms?

Thanks for any and all input!!

- Bill

 

[Olaf Baeyens]

This is contrary to the way IDE-generated code behaves in purely managed

apps (C# or VB.net), hence my confusion about the stability of VC .net.

There is a still a lot of work for Microsoft regarding a user friendly
developer interface, but they are on the right track in my opinion.
There are some issues, but there are also workarounds.

Also... why do event handlers automatically get dumped in the .h file?
Seems strange... C++ projects almost always, at least if style is an issue,
separate implementation from declaration (Cpp files), both for organization
and compilation issues. However, VC .Net seems to ignore this convention
and throw everything into the header files. Kind of annoying

My best guess is that they are preparing to lose the cpp files and move to
only h files in the far distance future.
Or at least lose the 2-file concept and move to a 1-file source because it
is easier to synchronize.
Again, in my point of view, a good choice since a lot of problems I fight
with is keeping on synchronizing the cpp with the h files.

C/C++ programers might feel uneasy about this, but it is a natural part of
an evolving language.
h and cpp files were a good concept back in the old ages, but maybe now it
is time to lose that.

Anyway, I guess the real question is, is VC .Net a good idea for a large
project? Is it fairly straightforward to combine alot of previously written
unmanaged code with managed interfaces and windows forms?

I have now a pretty good big ported project to .NET and contains both
conventional code and managed .NET code.
And it suprises me how well the port can be done. Parts of my functions
contain both managed and unmanaged code mixed together. In time the
unmanaged code will be replaced by managed code, but currently I do not have
time to port and test it all.

The biggest problem I faced was the security integration. It took some time
before I understood how to use it, and all problems I blamed on .NET turned
out to be misuse of .NET because I kept on trying to model it to unmanaged
C++ code. I had to unlearn unmanaged C++ in order to use managed C++ and I
am very happy about that now, since I can program faster, and create far
better state of the art, user interfaces with ess effort.

Also I do not see any noticable performance loss betwoon the unmanaged and
managed code.

The only negative point of .NET is that Microsoft does not provide the .NET
framework standard installed on user machines. It would be nice if the next
service Pack will automatically include the .NET framework. At this point
users must install the framework themselves, and this is still a huge
problem for most simple computer users.

 

[David Lowndes]

Anyway, one of the things is the code formatting. When adding event

handlers and such, the code is formatted like so...
...
with the brackets strangely indented.

Annoying isn't it!

Also... why do event handlers automatically get dumped in the .h file?

It's apparently that way because the form designer is a direct
implementation of what the C# designer does. I don't know if MS are
considering changing this in a future version (post Whidbey) or not,
but they are well aware that it's not nice C++.

Anyway, I guess the real question is, is VC .Net a good idea for a large
project? Is it fairly straightforward to combine alot of previously written
unmanaged code with managed interfaces and windows forms?

It's going to get better with VS2005, but as I haven't done any real
managed code development, I can't say whether it's good or bad
compared to the other .Net languages. All I know is that C++ lets me
do what I need to do whereas other languages tend to limit you in
someway - ways that often only become apparent with larger projects or
one's that aren't on the well-beaten track.

Dave

 

[The unProfessional]

Thanks for the input guys, I appreciate it.

Right now I'm using C#... but I'll consider using managed c++ for some of
the other tools I need to build soon.

In big projects, using only h files could get nasty, because a modification
to a single h file would reguire a recompile of tons of files. With cpp
files, compiles are generally much faster when only implementation (cpp) is
changed. Maybe I'll get used to it in time

Olaf: what do you mean by "Security Integration"??

Also, have you guys had problems with obfuscation? Do you use code
obfuscators? I'm worried they'll trash my code, but .net apps can be
reverse engineered in a snap.



----- Original Message -----
From: "The unProfessional" <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.vc
Sent: Monday, October 11, 2004 12:14 AM
Subject: VC .Net not mature?

 

[Olaf Baeyens]

In big projects, using only h files could get nasty, because a
modification

to a single h file would reguire a recompile of tons of files. With cpp
files, compiles are generally much faster when only implementation (cpp) is
changed. Maybe I'll get used to it in time

This is why I use C# for none-time critical stuff, like the user interface.
And I use managed/unmanaged C++ for performance critical stuff.

Olaf: what do you mean by "Security Integration"??

Default, a C# program (and probably managed C++) program have limited
security rights.
e.g.: Normally, it does not allow LAN rights, like opening files on a LAN,
or execute directly from a LAN network folder.
Create a C# program, copy it to a network drive and double click it will
generate a strange "access violation" like error that will scare anyone the
hell out of his life. This strangce error is just because the C# executable
does not have executable rights on that network drive. Copy it locally to
the C: drive and it works.

In order to make this work, 2 things must be in place.
* First you must provide in AssemblyInfo.cpp something like this:
The code below gives access just like a typical conventional executable,
which is unrestricted.

[assembly:SecurityPermission(SecurityAction::RequestMinimum,
UnmanagedCode=true)] // Request to run unmanaged code
[assembly:FileIOPermission(SecurityAction::RequestMinimum,
Unrestricted=true)] // Request complete File IO functionality
[assembly:RegistryPermission(SecurityAction::RequestMinimum, All="*")] //
Request complet access to the registery key
[assembly:ZoneIdentityPermission(SecurityAction::RequestMinimum,Zone=Securit
yZone::NoZone)] // Request unrestricted zone

It is up to you to restrict the rights, by removing unnessecary rights.

* Second the administrator must also give you rights, to run on a network
drive.
Normally this is done by goin to control panel/ Administrative Tools/
Microsoft .NET Framework 1.1 Configuration
But I do not prefer this approach since it is too complicated to let the
user do this configuration.

But there is also good news, this configuration can be automated, but you
must use the installer to configure it.
A C# program running on a network drive cannot register itself, but you can
provide a Installer class with the necesary configuration options and if you
provide the [RunInstaller(true)] attribute in that executable. Then the
installer program can load this class and execute the code with enough
rights.

I have to admit that I still do not understand every aspect but I keep on
learning.
I love this security thinng because it lets me create applications that are
more resistant to virusses and worms.
For example if I create a stupid clock, that does not need Internet, then if
a Worm can infect it, it will still be prevented to access the Internet to
infect others. Imagine that your complete OS contains code like this, then
Worms and Virusses would not have as much chance to spread itself.

 

[David McClarnon]

To the VC .Net'ers out there...

I noticed alot of strange behavior in the way VC .Net apps behave in the
IDE. It's a bit odd, so maybe people have workarounds. I'm worried to
devote my project to the managed/unmanaged heuristic because these early
issues make me feel VC .net just isn't mainstream (or complete) enough yet
to depend on.

Anyway, one of the things is the code formatting. When adding event
handlers and such, the code is formatted like so...

public void Func (...)
{

}

with the brackets strangely indented. Also, the functions are often jammed
right up against another, and even sometimes, the bracket scope gets messed
up.

public void Func1 (...)
{

public void Func2 (...)
{

}
}

.. automatically, by the IDE... = BAD!

This is contrary to the way IDE-generated code behaves in purely managed
apps (C# or VB.net), hence my confusion about the stability of VC .net.

Also... why do event handlers automatically get dumped in the .h file?
Seems strange... C++ projects almost always, at least if style is an issue,
separate implementation from declaration (Cpp files), both for organization
and compilation issues. However, VC .Net seems to ignore this convention
and throw everything into the header files. Kind of annoying


Anyway, I guess the real question is, is VC .Net a good idea for a large
project? Is it fairly straightforward to combine alot of previously written
unmanaged code with managed interfaces and windows forms?

Thanks for any and all input!!

- Bill

I generally only reserve C++.NET for when I need to use it. Then I write
an assembly to wrap up whatever native code I want to access, and write
the vast majority of the code in C# instead.

Why ?

I find C++.NET a pain to write in to be honest. And with the .NET
architecture it's so easy to link an assembly into a C# project.

C# is much better set up to use .NET than C++. For a start the namespace
character is period not colon which means I only have to hold down one
key instead of 2 (shift to get colon).

And the intellisense is much better.

This is just my way of working which has been built up over about the
last year and a half.

David.

 

[Olaf Baeyens]

I generally only reserve C++.NET for when I need to use it. Then I write

an assembly to wrap up whatever native code I want to access, and write
the vast majority of the code in C# instead.

I find C++.NET a pain to write in to be honest. And with the .NET
architecture it's so easy to link an assembly into a C# project.

And the intellisense is much better.

And you forgot that the build is lightning fast.

And documenting code is also much better. Just type in the /// and there
you get the xml remarks ready to be filled in.
I really miss this in C++.

But I agree with you, I moved big parts of none-performance critical C++
code to C# and now I can develop much faster.
Actually, the project takes the same time to develop, I can just add far
more features in the same time.

But to be honest, both C++ and C# does a great job at .NET code.
The fact that you can mix C# and C++ dll's to create one big project is a
big step forward, since you get the best of both worlds.

 

[Tomas Restrepo \(MVP\)]

Hi Olaf,

And documenting code is also much better. Just type in the /// and there
you get the xml remarks ready to be filled in.
I really miss this in C++.

C++/CLI in whidbey will have that

 

[Olaf Baeyens]

And documenting code is also much better. Just type in the /// and
there

C++/CLI in whidbey will have that

Nice, nice!
I always admire the fact that C++ compiler developers keep on extending the
C++ to keep it competing with other newer languages like C# but without
losing the backwards compatibility. In my opinion this cannot be a easy
task.