|
IMO, C# is a nice language, but it is let down by the primative set of libraries that make up the .NET framework. (primitive compared to what MFC offers) Of course, the framework is improving with each release and eventually it will be the defacto way of developing for windows.
A lot depends on how much legacy code you have in C++. If you have a great deal of time and money invested in a C++ codebase then moving may not be the best thing to do.
I have a lot of legacy apps that are C++/MFC, and I won't be migrating any of those away from C++. I have 10 years worth of development time invested in C++/MFC, so moving to C# will mean a lot of time learning the new language and how to get the best out of it.
I recommend you read the book 'Inside C#' by Tom Archer. This will give you a nice detailed look at the language, which should give you a clearer picture of where it is better than C++ and where C++ still has the advantage.
A lot depends on the kind of applications that you write. If you write a lot of database related applications, then C# is a lot quicker to use than C++. C# and ASP.NET make writing web-apps so much easier too.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
The biggest difference is that .NET runs under a managed runtime, i.e. the Common Language Runtime (CLR) manages all memory and enforces certain constraints such as code-access security and native function calls. Of course, C/C++ has a runtime but that really provides simple execution.
As someone else mentioned, the base class library - the library that ships as part of the .NET Framework is lacking. This "lack" of functionality is redeemed by being able to P/Invoke (call native functions), control marshaling, and to perform COM interop very well (since .NET is a progression of - not a replacement for - COM).
The most important thing to understand is that C# is just one of many languages used to write .NET applications. All the compilers produce Intermediate Language (or IL, like Java bytecode, if you're familiar with that) except for the VC++ compiler which - with the /clr switch - is capable of create mixed mode assemblies where native instructions are embedded. The IL from any language is still contrained by the Common Type System (CTS) and the CLR and, hence, can be used by any other language that targets the CLR, but there might be some slight differences since some compilers optimize better / differently from language to language, and because some compilers don't support certain conventions in the language (like VB.NET cannot yet support unsigned integers or unsafe contexts).
I would recommend - as someone else hinted - that you don't just jump on board the .NET wagon. Understand the framework first. Also decide if you need to move the application. Remember, you would then have to deploy an average 20 MB runtime to each client and worry about versioning (versions in .NET are actually used to resolve Types whereas with native DLLs they're just for informational purposes).
If you do want to move to .NET development, I do recommend C#. If you already have a large codebase of libraries, you can turn-on the /clr switch in your project options in VS.NET 2002 and higher for your C++ to produce a mixed-mode assembly and use those in your application development, though you should eventually rewrite those libraries in pure .NET using whatever language you like. Managed C++ is still C++ so - as you know - there's a lot of extra code you have to write but not near as bad as C++ because you don't have to worry about memory as long as you use 100% managed code. C# is also syntactically similar to C++ so you shouldn't have too many problems picking it up.
So, when you think about .NET development, don't think of it so much in terms of languages but in terms of the base class library, IL and the CLR, and CTS. The language is just a means to an end, where those ends are almost the same and can be used by any other means (i.e., a library written in C# can be used by a library written in VB.NET which can be written by an appliction written in PERL.NET).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
The .NET world is a totally different beast. C# or any of the other langauges are only the least of things. The framework is what has moved me to .NET as much as anything else. I do not remember for sure but it is something like 8,000 class and it is a fully class based framework, no more SDK.
If you are not developing something machine dependant (this includes heavy graphics), I doubt you will find much missing. I have worked with it now for two years and have not had any stoppers.
The C# language is of course my favorite but that comes from a background of twenty years of C/C++, so it is the closest.
There are a few quirks in the langauge, but overall it is okay. Being able to use other modules from VB.NET or others is really nice.
I will warn you though, be prepared to rethink software design in general. There are so many ways of doing things in .NET that it can be time consuming figuring out the best way to go. Now that we can so easily combine networking and software, the scope of our programs are increasing.
Why settle for some silly import of data when you can use a web service and streamline it. Maybe you application is a resource hog, now you can easily spread its tasks over multiple computers with .NET remoting (that actual works  ). Now that we can use a lot of the backend of applications for both web and windows application, we have to start thinking even more of reuse of code.
Now, for time savings!! Yep, it has drastically cut down my development time. I do not know about you, but for me I usually run at 25%-40% of the time of application development debugging. This can range from simply null pointers or dll mistmatches up to several days tracking down bugs.
Not with .NET. My debug time has dropped to almost nothing. Maybe 1%-2% of the time I will be debugging. Very trival now compared to the old C++ days. The code is so simple that errors jump in your face quick quickly. Also a huge reduction in coding since I get more done with less, so it is less to debug.
And remember, this is only the first version, 2.0 is supposed to be a lot better
Of course all this will help when Longhorn comes to market 
Rocky <><
www.HintsAndTips.com
|
|
|
|
|
Many thanks for your answers.
I consider the views of other devleopers to be far more reliable than the advertising from Micrsoft. However on this occasion you appear to have very little bad to say about C#. I think I shall give it a go.
Many thanks for your help
Dave Collins
|
|
|
|
|
By all means learn C#. I think you will like it. But don't expect to say goodbye to C++. Its just to darn powerful.
For me MFC is still way more powerful than Windows.Forms, but then there is more work involved.
Saying that things like COM+ are incredibly easy in .NET.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table.
Shameless Plug - Distributed Database Transactions in .NET using COM+
|
|
|
|
|
Hi All!
How can we get the 'Folder Browser Dialog' like ,we have have standard 'file open dialog'. Is there any component in .net providing this capability? or is there some APi, we have to use in order to open a folder browser dialog.?
Thanx in Advance
sorry for my bad English.
|
|
|
|
|
try this one, it have some limited.
Add System.Design into References. Use method ShowDialog() to show
using System;
using System.Windows.Forms;
using System.Windows.Forms.Design;
namespace WindowsApplication1
{
/// <summary>
/// this provides the BrowseFolderDialog for browse folders.
/// </summary>
public class BrowseFolderDialog : FolderNameEditor
{
FolderNameEditor.FolderBrowser fBrowser;
public BrowseFolderDialog()
{
fBrowser = new FolderNameEditor.FolderBrowser();
}
public string DirectoryPath
{
get {return fBrowser.DirectoryPath;}
}
public DialogResult ShowDialog(string txtDescription)
{
// set the Description label
fBrowser.Description = txtDescription;
fBrowser.StartLocation = FolderBrowserFolder.MyDocuments;
return fBrowser.ShowDialog();
}
~BrowseFolderDialog()
{
// destructor
fBrowser.Dispose();
}
}
}
|
|
|
|
|
There is System.Windows.Forms.FolderBrowserDialog in .NET 1.1 and up. For applications targeting .NET 1.0, you'll have to create a look-alike or encapsulate the SHBrowserForFolder API. There are several articles here on the CodeProejct site that discuss the latter option. The component I mentioned first is very easy to use, just like the OpenFileDialog and SaveFileDialog components.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I have questions about paging
Because paging may play important role in distributed application
And according to ".NET Data Access Architecture Guide" at MSDN there are three options to
Implement paging
1-Use the Fill method of the SqlDataAdapter to fill a DataSet with a range of results from a query.
2-Use ADO through COM interoperability and use a server-side cursor.
3-Implement data paging manually by using stored procedures
the article discuss this options
Each method have its advantage and disadvantage in performance and scalability and other things
the question is
What option you use in your Distributed Application and Why ?
If you have another method what is this method at what is it's advantage over those methods
thanks in advance
|
|
|
|
|
It greatly depends. Over what medium is it distributed? Does each client share in the processing of specific chunks of data?
If this application is deployed over the Internet using a DataSet is good because it is both serializable (which is good for both XML Web Services and .NET Remoting) and disconnected (better throughput). If each client processes parts of this data, you'll need something to delegate to the clients which rows they should be working on, or fill a DataSet with only the data they should process.
If your clients are on a LAN with the server as opposed to a WAN, the second method might be good because the server cursor will make sure that each client is accessing sequential data in a distributed manner. For an Internet application - as I mentioned above - the rate of data exchange will potentially be high which will result in congestion. You'll also have to take lengths to ensure that any data you in any object you send is serializable to transport via XML Web Services or .NET Remoting. If you use raw sockets, serialization isn't a problem but you might have problems using sockets (for instance, securing them if they need to be secured and bi-di communications can be combersome.
As far as stored procedures go, you'll still need something to track which block of records to delegate to the next client. A Singleton object exposed through .NET Remoting could help and it won't even have to worry about serializing data if you just pull it using a SqlDataReader or something. If this is a WAN- or Internet-deployed application, a SqlDataReader won't work, and even if it did it would create a high rate or smaller chunks of data which could lead to congestion and timing issues.
Depending on your answers to the first two questions, I hope the following paragraphs are of some help to you.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Thanks Heath , Guillermo
i agree with you but i have a comment about using Ado server side cursor
as heath mentioned some of its advantage i see that keeping long time open connection
with the database server and the number of the round trips between the client and server
may be unaccepted and may be this solution violate the philosophy of ado.net
what i want to say make this last solution.
what is your opinions ?
TO Heath :
i posted another quetsion about paging decision at sql,ado.net forum may you take a look?
|
|
|
|
|
I completely agree with Heath. All depends on how you are planning to deploy your application.
I'm just finishing a distributed application, and the enviroment I'm using is a LAN, so the customer wanted online notifications of data update.
What I did was build a service that listen to all modifications done by the clients, and fire events when the update is complete, so all the clients listen to those events and react depending on the data they are showing at the moment.
I used disconected data (DataSet and DataTable).
A simple Client / Server architecture, but it works perfect and fast in a LAN enviroment.
Free your mind...
|
|
|
|
|
I have constructed a COM object in VB6 that exposes various methods to handle custom files. This object works very well when I use it from a normal VB6 project, but when I use it through COM Interop in a C# application a strange error appear:
Inside one of the functions in the COM dll I use the FileExists method on a FileSystemObject. When this method is called from the C# code FileExists returns false, even though the file exists. When the same method is called with the same filename as parameter in VB everything works.
Anyone who have any idea of what I am doing wrong?
Rickard
|
|
|
|
|
You should debug both projects (start debugging the C#/.NET client in VS.NET and then start your VS6 and attach to the process) and see what string is getting passed to the COM object. The behavior shouldn't really change from caller to caller except when parameters differ. A different value might be getting marshaled to your COM object than what you're passing from your C# code.
My initial thought is that there is a Unicode vs. ASCII problem with string encodings. .NET stores Unicode strings internally and your VB6 control might not be expecting that. See the VB6 StrConv function for information pertaining to converting from/to Unicode strings.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Good tip! I had actually start to think in those lines!
Thanks!
Rickard
|
|
|
|
|
The COM dll is written in Visual Basic. Could you describe to me how I can attach to this process and debug it using VB6? I can't find any attach to process in my VB6..
Rickard
|
|
|
|
|
I solved it!
Found a good article on this URL
http://support.microsoft.com/?kbid=811658
Rickard
|
|
|
|
|
Hi,
I have now debugged my application and the string seems to be alright, but it
still doesn´t work, or actually it worked for a while, but suddenly
the same error occured again.
Could this be some kind of access problem?
Could it make a difference in I run the com in process or out of process?
Rickard
|
|
|
|
|
No, it would be an access problem if one client could access it via your COM component but another client couldn't, unless they were running with different credentials (something you have to manually do through several steps). This sounds more like a marshaling problem as I mentioned before.
Your COM component can only run as an out-of-process server if it is a stand-alone executable (.exe), so that's not even a valid case.
Since it worked before, you're obviously doing something right. Since it changed, you should figure out what changed. Two compiled applications don't magically change. If this is a marshaling problem, make sure you understand that Windows 9X/ME (Windows) use ASCII while Windows NT/2000/XP(/future versions of Windows) (Windows NT) use Unicode. I can't remember exactly how VB handles strings, but you can code your .NET applications to P/Invoke methods using either ASCII or Unicode depending on the OS type, which it will automatically do for you (see CharSet.Auto). I don't remember exactly how VB deals with the different OSes. Find out how that works and make sure your .NET application marshals the string accordingly appropriately on either of the Windows OS system type.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
One other quick thought, not likely but you might check permissions and the creditials being used.
Rocky <><
www.HintsAndTips.com
|
|
|
|
|
Thanks, will keep this in mind.
Rickard
|
|
|
|
|
Hi,
I have now debugged my application and the string seems to be alright, but it
still doesn´t work, or actually it worked for a while, but suddenly
the same error occured again.
Could this be some kind of access problem?
Could it make a difference in I run the com in process or out of process?
Rickard
|
|
|
|
|
I have created my own Rebar Control and I am having issues on Windows 2000 machines.
When creating the handle it throws an Win32Exception with the error "Invalid window class name". It works fine on Windows XP machines.
The following is my CreateHandle method and CreateParams property. Any ideas?
protected override void CreateHandle()
{
if (!RecreatingHandle)
{
// Initialize Cool Bar Common Control
INITCOMMONCONTROLSEX initCommonControls = new INITCOMMONCONTROLSEX(); // I set Size field in constructor
initCommonControls.Flags = InitCommonClasses.COOL_CLASSES | InitCommonClasses.BAR_CLASSES;
SafeInterop.InitCommonControlsEx(initCommonControls);
}
base.CreateHandle(); // <-- Exception thrown here
}
protected override CreateParams CreateParams
{
[SecurityPermission(SecurityAction.LinkDemand, Flags=SecurityPermissionFlag.UnmanagedCode)]
get
{
CreateParams createParams = base.CreateParams;
createParams.ClassName = Interop.REBARCLASSNAME;
createParams.Style |= (int)(CommonControlStyles.NORESIZE | CommonControlStyles.NODIVIDER | CommonControlStyles.NOPARENTALIGN);
if (_Borders)
{
createParams.Style |= (int)RebarStyles.BANDBORDERS;
createParams.Style |= (int)(RebarStyles.VARHEIGHT | RebarStyles.AUTOSIZE);
return createParams;
}
}
}
|
|
|
|
|
You must make sure that your window class is registered using RegisterClass(Ex) API. InitCommonControls does this for classes defined in the common controls library, but any custom classes must be registered by you.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I found out what is was. The INITCOMMONCONTROLSEX structure had the size and flags fields the wrong way, so the call to InitCommonControlsEx was failing. It's just weird that it worked fine Windows XP, sometimes is really bad for developing on, because it hides errors.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
