.NET (Core and Framework)

Ruchi Gupta11-Dec-03 6:51

Ruchi Gupta

11-Dec-03 6:51

Could you please send the link to where it says how we can build the Windows Application setup, so that it reduces the burden of installing .NET framework on client's machine before deploying/installing .NET windows application.

If this is really true, it will save me some of work I do for Application deployment.

I didn't quite understand what needs to be done for such deployment from your reply.

Any help is appreciated.

Thanks
Ruchi

Stephane Rodriguez.11-Dec-03 7:17

Stephane Rodriguez.

11-Dec-03 7:17

Here is an entry-point[^]. (watch out for the links)

And don't forget to check out what's in your VS.NET cds.

[update] Yet another bootstrapper[^].

RSS feed

Not Active11-Dec-03 7:02

Not Active

11-Dec-03 7:02

You must also distribute MDAC 2.7 or higher

Stephane Rodriguez.11-Dec-03 7:18

Stephane Rodriguez.

11-Dec-03 7:18

Yeah, if the app is using System.Data.*

RSS feed

.NET Languages

John L. DeVito6-Dec-03 8:52

John L. DeVito

6-Dec-03 8:52

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."

J. Dunlap6-Dec-03 9:24

6-Dec-03 9:24

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.

"Peace is not merely a distant goal that we seek, but a means by which we arrive at that goal." -- Martin Luther King Jr.

FLUID UI Toolkit | FloodFill in C# & GDI+

Nick Parker6-Dec-03 9:32

Nick Parker

6-Dec-03 9:32

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

John L. DeVito6-Dec-03 9:37

John L. DeVito

6-Dec-03 9:37

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."

J. Dunlap6-Dec-03 9:56

6-Dec-03 9:56

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.

"We must pursue peaceful ends through peaceful means." -- Martin Luther King Jr.

FLUID UI Toolkit | FloodFill in C# & GDI+

Colin Angus Mackay7-Dec-03 6:09

7-Dec-03 6:09

jdunlap wrote:
VB.NET is much less optimized than C#, so it runs slower

Really? Confused | :confused:

Now why would Microsoft do a thing like that? Poke tongue | ;-P

--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#

J. Dunlap11-Dec-03 9:58

11-Dec-03 9:58

See this article: A statistical analysis of the performance variations of assorted managed and unmanaged languages[^].

Note that I do not mean that VB.NET is considerably slower; only that the substantial lack of optimization makes it somewhat slower. Wink | ;)

"We must pursue peaceful ends through peaceful means." -- Martin Luther King Jr.

FLUID UI Toolkit | FloodFill in C# & GDI+

Anonymous9-Dec-03 21:33

Anonymous

9-Dec-03 21:33

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.

J. Dunlap11-Dec-03 10:00

11-Dec-03 10:00

See the survey currently on the CP home page[^].

"A journey of a thousand miles begins with a single step." -- Confucius

FLUID UI Toolkit | FloodFill in C# & GDI+

eggie527-Dec-03 7:22

eggie5

27-Dec-03 7:22

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 need help

LOSTTWARE.com5-Dec-03 13:20

LOSTTWARE.com

5-Dec-03 13:20

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

Re: I need help

tbrammer9-Dec-03 2:11

tbrammer

9-Dec-03 2:11

>> 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

Re: I need help

SiddharthAtw12-Dec-03 1:09

SiddharthAtw

12-Dec-03 1:09

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.

Remoting Port problem

youmesh4-Dec-03 19:08

youmesh

4-Dec-03 19:08

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 ?.
Confused | :confused:

Umesh.b

Combining assemblies

Arash Sabet4-Dec-03 9:06

Arash Sabet

4-Dec-03 9:06

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

Colin Angus Mackay7-Dec-03 6:12

7-Dec-03 6:12

Take the source code of each assembly and put it all in one project. Then compile it all into one assembly.

--Colin Mackay--

Anonymous7-Dec-03 9:55

Anonymous

7-Dec-03 9:55

One project is in J# and another is in C#. How can I combine them in a single project!

Colin Angus Mackay7-Dec-03 13:58

7-Dec-03 13:58

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--

Arash Sabet8-Dec-03 2:28

Arash Sabet

8-Dec-03 2:28

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

Colin Angus Mackay8-Dec-03 3:21

8-Dec-03 3:21

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--