.NET (Core and Framework)

Re: MC++ or C# for user controls

8-May-04 6:50

Either C++ or C# are suitable. VC++ 7.0/7.1 are fullly capable in .NET. You get the best of both worlds using C++ because you have full access to Win32 without resorting to Interop as in C# Wink | ;)

Use the language you are most comfortable with.

deckards29 wrote:
C# may be more secure because each external API/struct will have to be specifically redeclared but is it worth it?

It won't have to be redeclared. If you don't want something visible, make it internal or private.

If you're allowing COM interop so others can use the custom controls as ActiveX controls, you can also mark them with [ComVisible(false)] or declare them as above.

Ian Mariano - Bliki | Blog

"We are all wave equations in the information matrix of the universe" - me

Julien Delezenne9-May-04 2:43

Julien Delezenne

9-May-04 2:43

Thank you.

The internal modifier looks good to hide the implementation with Win32 imports.

.NET advantage over JAVA

mmikey74-May-04 11:43

mmikey7

4-May-04 11:43

Hi everyone.
I'm developer on .NET platform, but I never was intrested in Java. Can you tell me any advantages .NET over JAVA? Or some advantage JAVA over .NET?
Thank you in advance!

Jeff Varszegi4-May-04 12:22

4-May-04 12:22

Here's how I see it, as somebody who uses Java and .NET every day:

.NET ADVANTAGES
---------------

1) Good to great integration with Windows, Active Directory, and other Microsoft products and services

2) Ease of integration with C++ code (in Java you must use JNI, not much fun)

3) The C# language is a little cleaner than Java and provides better support for OO development, with properties and a richer set of keywords. (A few things can actually subvert good OO design, like method hiding, but you don't have to use those features.) The language is more suitable for lower-level work than Java, while still providing all the features of garbage collection, multiple-platform deployment, etc.

4) The marketing muscle of Microsoft, nothing to sneeze at, means you'll be looking at green pastures for a while. Microsoft is also committed to supporting .NET for the foreseeable future, and has based much of their corporate strategy on it going forward.

5) The .NET runtime is better optimized for some things; object creation is less expensive in general, method-call overhead is a little less, etc.

6) The CodeDom namespace simplifies the task of dynamic code generation, something not supported in the Java core libraries

7) Excellent, excellent free documentation on everything you may want to do in .NET, with further support through the usually-excellent Microsoft Press books as well as authors of third-party publications (our own Nish and Tom Archer being a good case in point)

8) Ease of deployment for Web services is still far better than anything you'll see from a third-party Java tool IMHO, although I haven't seen the latest versions of Websphere Studio and BEA's tools

9) ASP.NET is better suited to RAD for presentation purposes. I'm sorry, JSP fans, but it's true; I know from experience.

10) Microsoft-centric developers are a little less likely to spend four hours a day at the water cooler engaging in object-oriented oneupsmanship.

ABOUT EQUAL
-----------

All in all, it seems to me that they're about equal in terms of what's provided in their base libraries. Their security models are equally powerful and extensible, although with .NET you'll find it easier to work with Active Directory than othwerwise, no surprise there. Runtime speed of code is about the same in my experience, although I'd bet that calling native code on Windows works faster in .NET than in Java. They both have open specifications. They both have support for embedded code and small devices, with .NET support on the latter growing all the time.

JAVA ADVANTAGES
---------------

1) Actual support for "write once, run anywhere". If you need to deploy on Linux or Unix, Java, C/C++, and/or something like Perl is still your best bet. Mono, the leading *nix implementation of the .NET framework, is still not as mature as the Microsoft implementation, and for reasons that'd require lengthy explanation, the two will probably never be fully compatible.

2) Better support for non-Microsoft technology. This is mostly just because of Java's longer history; while there are rabid .NET fans out there at this moment cooking up reams of open-source code to do just about anything imaginable, the jarheads have a head start. For instance, if you need to write an application to use multiple databases, just about every modern database vendor now provides a great type-4 JDBC driver, but support for .NET data providers is still not complete. (You can mitigate the effect of code branching by using a decent Data Access Layer in .NET.) Oracle and DB2 stored procedures can even be written easily in Java; both IBM and Oracle have invested heavily in the future of Java.

3) Lower cost of entry. I might make some people angry here, but you can still download Java for free and install it on your free Linux OS, and even run your applications on a free Java-based application server like JBoss, the same applications you developed on your free IDE. (.NET has free IDEs available also, such as SharpDevelop, which are great for the price but nothing near as good as Visual Studio .NET .) Total cost of ownership of a high-end site is debatable by wiser and more knowledgeable heads than I.

4) Better support for middleware, with the EJB standard. This is something that's currently lacking in .NET, although I'd guess that the plan is to sell extra "Yukon" licenses as middleware servers, since you'll be able to program stored procedures and other server-side objects in .NET-supported languages in that future version of SQL Server. (Of course, Jonathan Schwarz proclaimed the upcoming death of middleware in a recent issue of Java Developers' Journal. Also, Microsoft has chosen to go with a distributed-component model that is more services-oriented than Sun's; one can argue that this makes it less reliant on middleware from the start. Most applications don't need something like an EJB server anyway.)

5) A bigger developer community. This means you can get Java developers on the cheap, even easier than .NET coders. The .NET programming community seems to be more tightly knit, however, and is growing daily.

6) More access to the source and underpinnings of Java. In addition, there are many companies that provide Java Runtime Environment (JRE) implementations, in addition to Sun.

-Jeff

here, bloggy bloggy

mmikey74-May-04 12:45

mmikey7

4-May-04 12:45

Thank you Jeff!
Your message is very useful. If I can ask, what do you think, JAVA+Linux==.NET+Windows?
Thank you again!

Jeff Varszegi4-May-04 14:22

4-May-04 14:22

They're both viable platforms. A lot of it has to do with the specific situation. I have a lot of experience with Java, and I used to have a lot of animosity towards Microsoft as a company just because of the company I kept, but that's dwindling all the time and not something on which to base a purchasing decision. If you have a lot of Microsoft technology, .NET is the way to go, hands down. If you need to deploy mission-critical application on Unix, you have to go with C++ or Java.

I tend to think that Microsoft technology is better in general for small-to-medium-sized companies because it's very easy to learn, and productivity is easy to achieve. Like I said before, the RAD features of ASP.NET are currently unmatched; it seems to me that most of the in-house development needs for small-to-medium-sized companies are for database-driven Web applications, in particular reporting and intranet applications. Also, you won't get me to advocate buying into Java on this site, but I won't slam it either. You have to make your own decision!

Of course, you can always migrate your Java code to .NET; I have first-hand knowledge that the Microsoft-provided migration tools work well enough. On the other hand, it's not so easy to migrate .NET code to Java, but it can also be done, and you'll probably never need to do it.

-Jeff

here, bloggy bloggy

Mike Ellison8-May-04 4:46

Mike Ellison

8-May-04 4:46

Hi Jeff. Nice summary. We had a pretty low cost entry into .NET -- most of my first year's development with .NET came from the free .NET SDK download and a $30 text editor. It's not the funnest way to develop WinForm applications, but it was great for components and ASP.NET apps.

ian mariano8-May-04 6:51

8-May-04 6:51

You've probably seen this but #develop. And it's a free IDE Wink | ;)

Ian Mariano - Bliki | Blog

"We are all wave equations in the information matrix of the universe" - me

Jeff Varszegi8-May-04 7:08

8-May-04 7:08

Yes, it's really decent in my opinion. I also know people who've used WebMatrix and say it's pretty nice, although it doesn't have support for everything.

-Jeff

here, bloggy bloggy

Jeff Varszegi8-May-04 7:07

A licensed windows forms control on a web page

8-May-04 7:07

Thanks! I got started with my favorite editor and the command line, then started using SharpDevelop, then got VS .NET as part of our MSDN subscription at work, so I identify with you. I was perfectly happy working on the command line for a while; it meant that I didn't get bogged down learning how to use an unfamiliar IDE. I'm sort of a Luddite when it comes to this stuff-- I don't even use the .NET debugger, ever. I just use Console.WriteLine(), and haven't found a problem yet that I couldn't tackle with that! (I'm not knocking IDEs-- they get to be necessary just to manage files and class hierarchies as things get more complicated, of course.)

-Jeff

here, bloggy bloggy

Patrick Lassalle4-May-04 11:02

Patrick Lassalle

4-May-04 11:02

How can I use a licensed windows forms control on a web page? How is declared the license? Have I just to place the license file in the same virtual directory as the dll? It seems it is not the case.

Re: A licensed windows forms control on a web page

ian mariano8-May-04 6:59

8-May-04 6:59

See this article on MSDN as well as the QuickStart sample.

You can validate a license for design time and only provide designer support, etc. if your license exists. Otherwise you just perform only the run time services of the control.

Also take a look at the

<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcomponentmodellicfilelicenseproviderclasstopic.asp?frame=true" target="_blank">LicFileLicenseProvider</a>

class.

Ian Mariano - Bliki | Blog

"We are all wave equations in the information matrix of the universe" - me

SOAP Server

Patje4-May-04 3:15

Patje

4-May-04 3:15

We are currently investigating the use of SOAP as 'intermediate layer' between some complex modules.
.NET makes it very easy to create a 'Soap DLL' that is activated by IIS. Great.
However, we are considering to use this technology to access bigger server-style applications. These applications typically take several minutes to start up, handle a large amount of memory, and therefore cannot simply be recompiled into a kind of 'Soap DLL'.

Browsing through the Microsoft documentation I found an excellent AtlServer example that seems to do what I need. However, it would be much nicer if we could use the more modern .NET technology for this.
So here are the 'million-dollar'-questions:
- Is it possible, using .NET technology, to make a standalone .exe server-application behave like a SOAP-server via the HTTP protocol?
- Is it possible, using .NET technology, to make it accept SOAP requests via a message queue as well?
- If NO on the questions above, is using the AtlServer a step in the good direction or is ATL a dead-end?
- If YES on the questions above, where can I find good .NET examples on writing such a SOAP server?

Because I'm not sure in which forum to post it, I'll post it in 2 or 3 forums. Sorry if you get this multiple times.

Enjoy life, this is not a rehearsal !!!

Re: SOAP Server

ian mariano8-May-04 7:12