c#

[spud]

Anyone with c#.Net development experience willing to impart a few words of wisdom to an old timer like me? I like the look of .Net Remoting.... What are the best (paying) contract skills to consider?

[thunderlizard]

If you fancy the look of .NET remoting, go right ahead. As with anything, if you specialise in the flakier side of things you should be charging more and remoting certainly fits into that category. Also, the big firms started to cotton on to XML web services about a year ago.

[DimPrawn]

.NET remoting is a technology dead end.

http://www.theserverside.net/tss?ser...link&sp=l27235

You need to be looking at Indigo.

http://msdn.microsoft.com/webservice...o/default.aspx

Please do try and keep up!

[mcquiggd]

I agree with DimPrawn.



However, personally, I feel if you are building a .Net 1.1 application Remoting with a binary formatter over TCP-IP is probably the most efficient way to transfer data across distributed tiers that are internal to a company in a purely .Net platform. Use HTTP as the transport if you have to go through internal proxies for security reasons. It really isnt that complicated once you learn how to define the relevant config file entries and use those rather than embedded code. Indeed, the new config entries for Indigo are very similar.

But Remoting is dead when .Net 2.0 is fully embraced by the larger companies (say in two years time - a lot of large banks / financial institutions are still using VB6, ASP, VBA, Access and Excel for internal applications).

Thats one of the reasons to work with Web Services in place of Remoting. By developing an application that works with XML over WS now, the migration will be less painful. Also, with the WS protocols for security, policy etc now gradually becoming stable, and WSE 2.x available, it is fairly straightforward to build a functional WebService. The 'soon to be released WSE 3.0 will provide a simler migration path.

Its just that its overkill for the internal aspects of a distributed application that is solely .Net based. Horses for courses, and thats the decision to be made at architect level.

Check out the new MS Certifications for Technical Architects - you have to submit and (it seems) present a number of solutions to given problems to a panel of people who are already certified MS .Net 2 architects.

A closed shop in the making, methinks.... how many local certified MS .Net 2 Architetects want competion from you...? Ill wait to see how this pans out before even attempting it.

[mcquiggd]

To summarise MS:

"
For each of the current technologies whose future is deeply affected by the advent of Indigo, developers need to understand two things: whether applications built on this technology will interoperate with applications built on Indigo, and how much work it will be to port applications from this technology to the Indigo environment. Here's a short description of how each technology addresses these issues:

ASP.NET Web services (ASMX): Web services built with ASMX will interoperate with Indigo applications. Since ASP.NET Web services and Indigo both support standard SOAP, this shouldn't be surprising. Moving existing ASP.NET Web services code to Indigo will require some mechanical work, but should still be straightforward. The basic structure of the two technologies is quite similar, so for the most part only attributes and configuration files will need to be changed. More advanced features, however, such as SOAP Extensions, will not be directly portable to Indigo. Instead, they'll need to be re-written using the extensibility options that Indigo provides.

.NET Remoting: applications built on .NET Remoting will not interoperate with applications built on Indigo—their wire protocols aren't compatible. Moving existing .NET Remoting code to Indigo will require some effort, but it will be possible. Anyone who's built custom .NET Remoting extensions, however, such as channels and sinks, will find that this code won't port to the new world. Similar extensions are possible in Indigo, but the interfaces for doing it don't match those in .NET Remoting.

Enterprise Services: to allow an existing Enterprise Services application to interoperate with Indigo clients (or other web services-based software), a developer can identify exactly which interfaces in that application should be exposed. Using an Indigo-supplied tool, service contracts can then be automatically created for those interfaces and exposed via Indigo. For existing clients of Enterprise Services applications that aren't built on the .NET Framework (and for other purely COM-based clients), an Indigo moniker is provided to allow straightforward access to web services. The effort required to port existing Enterprise Services applications to run directly on Indigo will be similar to what's required to port ASMX applications. Much of the work, although not all of it, will be straightforward mechanical changes to attributes and namespaces.

Web services Enhancements (WSE): WSE is Microsoft's tactical solution for implementing Web services applications that require some or all of the functions provided by the WS-* specs. Applications built using WSE 1.0 and WSE 2.0 won't interoperate with applications built on Indigo. Applications built on WSE 3.0, which will be shipped before Indigo is released, will interoperate with Indigo applications, however. For portability, the story is similar to the technologies already described: some amount of effort will be required to move existing code from WSE to Indigo, although this effort will be minimized for applications that use the final WSE version.

MSMQ: because Indigo's queuing functions are built on MSMQ, queued applications built on Indigo can interoperate with queued applications built directly on MSMQ. Porting applications from the System.Messaging namespace provided with the original .NET Framework will require some work, since this earlier interface is different from what Indigo provides. Once Indigo ships, developers should use it rather than System.Messaging to create most MSMQ-based queuing applications.

Before Indigo is available, the best technology choice for distributed .NET applications that don't need queuing is probably ASMX. It's simple to use, and it also provides the smoothest migration path to Indigo. Enterprise Services can also make sense for applications that need the things it provides, such as distributed transactions, while MSMQ remains the right choice for queued applications. .NET Remoting, however, should be used primarily for communication between two application domains in the same process. ASMX is a better choice for direct application-to-application communication in most other cases.
"

[Joe Black]

I agree with DimPrawn and mcquiggd.

"Also, the big firms started to cotton on to XML web services about a year ago"

[dork]

I agree with Joe Black

[mcquiggd]

I agree with .... Dork...

[sasguru]

Is this the most boring thread ever? Do try and keep up up boys, the future is in moving up the value chain, not learning new technology.

[mcquiggd]

Well, most roles at the moment seem to be investment banking or working for consultancies... and I keep being herded towards Team Leadership / Management.... when I simply want a Technical career path....