- The .NET Framework
- A programming environment for web services, dynamic HTML sites, GUI and console programs. Or think of it this way: A big library of common business "controls".
- Visual Studio .NET
- The latest version of Microsoft's programming IDE. Of course this supports the .NET Framework and a number of languages that Microsoft has ported to it.
- The .NET Services
- A bundling term for Microsoft's server applications IIS, MS SQL Server and others. This is not new technology, and these applications do not use the .NET Framework. They can be used as building blocks in applications written with the .NET Framework.
- The .NET OS
- The name given during development to what is now "Windows 2003." "Windows 2003" comes with the .NET Framework and probably adds some .NET Framework features for applications that are not built with the .NET Framework, like code assemblies. [Who knows more?]
Discussion editTclBridge allows full access to Tcl/Tk from all .NET languages.That's through COM right? We have a number of packages referenced on the COM page that could help there.JJM 2003-01-09: Yes. It provides bi-directional communication with COM components. Tcl/Tk scripts may be evaluated from the COM side and new Tcl commands may be added via methods of COM objects. This allows for full Tcl/Tk based scripting of any application capable of using COM objects.Please see http://www.tclbridge.com/html/CreateCommand.html and http://www.tclbridge.com/html/CreateDynamicCommand.html for more information.JJM 2008-09-16: Also, see Eagle.
From: Jeffrey Hobbs <[email protected]> Subject: Re: TCL/TK .NET Newsgroups: comp.lang.tcl Date: Tue, 07 Jan 2003 03:32:10 GMT Organization: ActiveState [...] Tk does not become any more x-platform than it currently is by having an IL implementation of Tcl. While this may be interesting in the research sense now, I'm not sure that there is much practical value. The .NET CIL is not well suited for dynamic languages, but there is also no limitation in using the current Tcl binaries on Microsoft's .NET OSes, as .NET is (currently) just an adjunct to the rest of the system. I'm not against seeing such an implementation, but I do try and understand the motivation behind seeking way (and trying to make sure people aren't misled by MS's misleading marketing mumbo-jumbo).
ulis 2002-01-07:Does not Tcl be already running under all Windows? What is the interest of having Tcl included in the .NET platform?My understanding is that Tcl is for all and .NET only for Microsoft.
Sean Halliday 2003-01-17:I think some people might be missing the big picture with .NET. The .NET IL gets compiled to native code at run-time. This makes it a big win over other byte-code languages that interpret the byte code. There is also a common type system (CTS) and common runtime. This allows code that was written in various languages to all work together. I am a big fan of Tcl/Tk and have been using it for about 8 years. I am now a big fan of .NET and I hate COM and ActiveX. Don't prejudge .NET just because it is from MS. As for Tcl/Tk being a .NET language, I don't know. I think if it was taken seriously, it could be done quite well. The big question is whether the .NET framework will really catch on. Anyway, I currently have Tcl and .NET working together just fine (without the need for COM.) I just write managed C++ code to access .NET. Since unmanaged code can call managed code, the Tcl commands I add can access .NET. I have even hosted C# windows forms in a Tcl app (again without ActiveX or COM.) This is the other really big win with .NET, it is very easy to write interfaces to existing C/C++ libraries - I didn't even need a Wizard :-)BR: That last sentence sounds more like Tk to me ;-)
Sean brings up an interesting idea on interopability. Let Tcl be as it is with an adaptor handling the connection. But I'm wondering (don't have VC7, so I can't test), as C# is so close to the C syntax, can Tcl's generic code be compiled by C# ?? If so, could a new platform directory be made for ngws ? -- DG
CL reacts: so many ideas are showing up here. I know I am confused.Davy, it would be entertaining to compile Tcl with C#. Maybe I'll try that when I can make time ... In any case, don't think you need VC7; there are open-source C# compilers. I'm working to make this more obvious on the C# Wiki page.In fact, an "adaptor" already exists: TclBridge. I'll let Joe Mistachkin explain more on that subject.I agree that there's an open question about whether .NET will succeed and be pervasive. No, wait, there isn't; MS's marketeers already have enough to ensure its longevity. The library is so big and compelling to conventional development shops, that they're switching to it from MFC, win32api, and such, so .NET is successful. With just a bit more lubrication, that'll be interpreted as success for the whole architecture.I'd love to learn more about the contrast Sean Halliday sketches between COM and .NET. Jacob Levy, for example, has written me that "Every '.NET' object is a COM+ object with some more stuff thrown in. If you don't need that additional stuff (you only need it if you're running on the CLR -- the common language runtime, their name for their VM) then calling through COM+ should work fine. Calling in the other direction -- from a '.NET' object to an old-style COM object -- might not work.I think Tcl has adequate mechanisms for talking to COM+ objects. All '.NET' objects support type information, so it should even be easy to auto-generate a procedure that makes this efficient as well as type-safe." That matches my understanding. So how can one like .NET so much while abhorring COM?
Sean Halliday 2003-01-18You really have to work with .NET and COM to understand why .NET is head and shoulders better than COM. Interoperability with COM and .NET is quite easy. You can easily access COM objects in .NET (one line of code brings in the COM object interface). There are tools to convert/wrap .NET code with COM. I think there even may be one to convert .NET controls to ActiveX. I wrote a Tcl/Tk based program that I eventually made an ActiveX control and it was a MAJOR pain! The .NET control version was WAY easier to write and didn't even require a wizard. This does not have much to do with the topic except that .NET will not just catch on because MS is pushing it. Every programmer I have talked to about using .NET likes it a lot - and they were all very sceptical :-)peterc 2008-02-19: Some big reasons why .NET is an interesting technology and may be useful for Tcl coders: (1) Dotnet on Windows and Mono elsewhere makes it fairly multiplatform, (2) It's a big tickbox in today's job and IT procurement market, (3) Dotnet is well documented, while COM isn't anymore, (4) There may be some efficiency pay-offs by calling Dotnet functions instead of their Tcl/Tk counterparts, particularly on Windows, by virtue of the Dotnet variant not using Tk's X11 emulation layer (XLEL).
SC: This all sounds great and good but is there any evidence that .NET will be anything but the next generation of the Windows API? I realise that mono is more cross-platform but will it ever catch on enough that one could hope to deploy to Mac and Unix based systems and gain some advantage over the current Way of Things?
Technical points: COM interoperability is slower than pure COM or pure .NET (true?). REGASM.EXE can be helpful in interoperability, because it creates the type libraries and registers them for COM.
Tcl Interpreter in C# Application code example for embedding Tcl in C# Application
A Tcl/.net interop solution would allow Tcl script to use the entire .net framework and any other CLS compliant assembly without sacrificing the huge investment made in the existing Tcl interpreter and associated libraries. If someone were to write such a bridge they could take advantage of the ScriptingExtensions for .net library that has been developed for rubydotnet. 
JH: has written, "... in general, Tcl works just fine in the .NET world as an unmanaged component. Since that's true of a lot of stuff, there is nothing wrong with just assuming that your Tcl works fine on a '.NET desktop'."
Peter da Silva:Calling Tcl from C# isn't all that exciting to me. What I want to see is something like this:
#!/usr/bin/tclsh using System import Console -from System Console WriteLine "Hello World!"Whether this is a managed or unmanaged application isn't all that interesting, I'm just here for the scripting.
See: Tablet PC
Rather remarkably, there's a Jacl.NET, tclcsharp and Eagle.Even more remarkable is that Jacl runs unmodified in .NET, through use of IKVM  and 
[veb] 2010-09-30 18:04:34:Hi friends,I am working on an application which involves both TCL command line and C# .NET based application. C# .NET application is a console based wherein it outputs the data it sniffs to the console. At a same time, it wait for the user input. We want tcl to invoke this application .exe and then inject some input to the console such that it is read by the .exe console application. I had success invoking the .exe from tcl command based utility, however, I did not get the control back to the tcl which I should. I do not have any previous experience working with it. Can you please advice what causing the problem? Is it the .NET framework or something else??Thanks
Page Authors edit
- others ...