|
You must also distribute MDAC 2.7 or higher
|
|
|
|
|
Yeah, if the app is using System.Data.*
RSS feed
|
|
|
|
|
Heyas all,
I'm comming from the *nix dev, attempting to learn some Windows now. My question is, Is there a particular reason a programmer would choose say VB.NET over X#.NET or vice versa? Do all the languages get to the same place and it's just a matter of which langugage the programmer likes better or is each language used for a different purpose.
Thanks all!!
Kha0s
"There are 10 types of people in this world; Those that know binary and those that do not."
|
|
|
|
|
kha0s wrote:
Is there a particular reason a programmer would choose say VB.NET over [C]#.NET or vice versa?
Well, for the most part, they're the same as far as what they can do. I find C# to be more concise and readable. Also, you can use pointers - although they aren't necessary for that much. I use them for image processing, and that's about all.
Really, it all comes down to syntax and personal preferences.
|
|
|
|
|
Programs that are written in C# or VB.NET all compile down to the same MSIL. Typically it breaks down to your comfort level with the language. In fact the only differences you should see in the MSIL of a C# vs. VB.NET should be compiler optimization.
-Nick Parker
DeveloperNotes.com
|
|
|
|
|
So if a programmer (well ok me) were comming from a unix environment and knows C/C++ like the back of his(my) hand, it would generally make sense to choose C# as his(my) language of choice. Unless he(I) wanted to learn VB.
kha0s
"There are 10 types of people in this world; Those that know binary and those that do not."
|
|
|
|
|
kha0s wrote:
it would generally make sense to choose C# as his(my) language of choice
Yes. BTW, one more thing I forgot to say - VB.NET is much less optimized than C#, so it runs slower.
|
|
|
|
|
jdunlap wrote:
VB.NET is much less optimized than C#, so it runs slower
Really?  Now why would Microsoft do a thing like that? 
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Enumerators in .NET: See how to customise foreach loops with C#
|
|
|
|
|
|
Survey of .NET Languages Usage
There are always lengthy discussions about which .NET language is better: C# or VB.NET. However, I am really interested in finding actual figures indicating which .NET language is primarily used in the real world. Not being able to find any legitimate survey with a high sampling rate, I decided to create my own poll here:
http://216.119.78.155/minh/dotnetsurvey.html
Minh.
|
|
|
|
|
|
I think Microsoft favours C#... Hence there will be alot more support for it in the future, compared to the other .Net languages.
/\ |_ E X E GG
|
|
|
|
|
I am currently a Visual C++ V 6.0 user. I have an extensive project. Probably as much code involved as VC 6.0. I have read an article about the .Net having CVS capability. Also, I have found that every time I do a search for Visual C++ 7.0, .net comes up. I figure that .net is what came after 6.0 Will I be able to import my incomplete, 6.0 project into .net with no problems? Will all of the code still function? I am using MFC allot. Don't know. Hopefully one of you do.
Thanks allot for your time in reading this,
Josh
LOSTTWARE.com
|
|
|
|
|
>> I have read an article about the .Net
>> having CVS capability
I don't know about that.
>> I have found that every time I do a search
>> for Visual C++ 7.0, .net comes up.
>> I figure that .net is what came after 6.0
That's right. The current version is .NET 2003, which is also called VC 7.1. VC 7.0 (.NET 2002) is not sold any more.
>> Will I be able to import my incomplete,
>> 6.0 project into .net...
Yes. You can import dsp project files from VC60. .NET will convert them to .vcproj project files without changing your original DSPs.
>> ...with no problems? Will all of the
>> code still function? I am using MFC allot.
Propably NOT. I had to port our C++ application to .NET 2002. The module size is about 10MB, also using much MFC. There are some API changes to .NET. One thing, that took me much time was, that CString is no class anymore but a typedef to a ATL template class. All forward references like
class CString;
that we used in headers had to be removed.
The .NET's compiler is much more restrictive than the VC60's (what is good). You may have to fix some bugs, that passed the VC60 compiler.
The following reflects my personal experience with .NET 2002 and our C++ projects:
Compared to VC60 the .NET IDE is
- unstable (especially the debugger)
- unreliable
- slow
- Resource hungry
- MUCH less user friendly.
In fact the most important functions of the source code browser are gone. You don't get Call Graphs and Class Hierarchies anymore!
I say "unreliable" because .NET seems to forget to recompile sources after header changes. I've lost many hours hunting down bugs, that just disappeared after a complete rebuild.
I'm sure if you have a huge project, you'll cry tears of pain if you have to use .NET 2002. I did. Maybe .NET 2003 is better. Unfortunately I cannot use it.
There are also some improvements in the IDE. The project management is much better, the editor was improved, you can browse over all projects in your workspace... Sure C# and the .NET Framework are great too. But for me, working with .NET on a huge C++ project just S U C K S.
-- Thomas
|
|
|
|
|
That was a really eye opener for me. What I know from experience VC++ debugger is the most reliable one. Any way it was a great message.
|
|
|
|
|
Hi
In remoting we cannot register more than one object to the same port. If we have to expose number of object over remoting we end up in opening lot of ports. Its there is a way in .NET remoting so that I can register more than one object on same port? Or should I have to change my design so that I aggregate objects in parent and expose the parent by remoting ?.
Umesh.b
|
|
|
|
|
Are there any tools in VS .NET or somewhere else to merge a bunch of assemblies together to create just one? If you know any resource for this, please let me know. Thank you.
Example:
Assembly1.dll + Assembly2.dll --> newAssembly.dll
Arash Sabet
Computer Engineer
E-mail: afifi@sympatico.ca
|
|
|
|
|
Take the source code of each assembly and put it all in one project. Then compile it all into one assembly.
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Enumerators in .NET: See how to customise foreach loops with C#
|
|
|
|
|
One project is in J# and another is in C#. How can I combine them in a single project!
|
|
|
|
|
Hmmm... Rather than just a straight forward "How do I do..." kind of question, what are the reasons behind it? Give me the history behind the question. Often in software development the final solution is more of a compromise of what you would like and what the situation will allow.
Why do you want to combine the two assemblies in to one? Why was one developerd in C# and the other in J#? What about just making one a dependancy of another? Or, allowing a third assembly that is dependent on the first two?
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Enumerators in .NET: See how to customise foreach loops with C#
|
|
|
|
|
There are no specific technical reasons and I just this is a request that must be done.
Arash Sabet
Computer Engineer
E-mail: afifi@sympatico.ca
|
|
|
|
|
Arash Sabet wrote:
this is a request that must be done
I don't think there is an easy answer to this. If a command from on-high has demanded that it must be done then it doesn't sound like the on-high commander has a great technical understanding.
Different .NET languages cannot be combined in the same project (to the best of my knowledge). The best I can offer is that the smaller one is rewritten into the language of the larger assembly and recompiled.
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Enumerators in .NET: See how to customise foreach loops with C#
|
|
|
|
|
Can al.exe combine two assemblies as a single one?
Arash Sabet
Computer Engineer
E-mail: afifi@sympatico.ca
|
|
|
|
|
Not out of the box... But if you look up MSDN for "Multifile Assembly Example" you will find how to create lots of MSIL module files, which can be used by the AL.EXE tool - So putting the two original assemblies together may just be possible if you can compile each to a MSIL module first and then use AL.EXE to link the modules together to make the assembly.
Mayme this is just me - but this seems like a bit of a hack. I'd still really like to know the reasoning about why these two assemblies must be made into one. I don't see that it matters having two assemblies instead of one. I think it would be a lot easier to manage as two assemblies rather than as two masquerading as one. I'm not sure about how the debugger will take to this arrangment (it might be clever enough to work out where everything is - but it could also really confuse it).
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Enumerators in .NET: See how to customise foreach loops with C#
|
|
|
|
|
Thanks for the reply.
As a matter of fact I have been requested to make it and I have not asked about the reason. I agree with you but I have to keep on mixing those.
Regards
Arash Sabet
Computer Engineer
E-mail: afifi@sympatico.ca
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
