Is there any readable, up to date (.net 4) MSIL Reference Manual?
There is a bunch of downloadable reference documents here.
Including the ECMA-335 Common Language Infrastructure documentation (pdf), dated June 2006, and other draft documents dated 27 March 2010.
Actually, scanning the pile of .Net, C#, ... books I own, Donis Marshall has a very good chapter on MSIL Programming in "Programming MS Visual C#2005: The Language". It's been updated to C#2008, but not to 2010 yet.
Related
In Ironpython site exists references to a language called VBx using DLR. But i can't find any reference to this in google. Where is it?
Edit: Is a Implement of Visual Basic 6.0 in DLR? if yes is so cool. Is more expected for people using VB6 yet and can't migrate because big frameworks.
From this mailing list post:
VBx was an implementation of Visual Basic on the DLR. It was first meant
to be in Silverlight, but the VB team decided they'd rather put VB.NET in
Silverlight rather than build a new implementation up from scratch. So, VBx
is on hold.
Apparently it's an implementation of VB in the DLR:
http://www.mail-archive.com/users#lists.ironpython.com/msg05933.html
Straight from the mouth of Paul Vick (long time VB architect)
What is VBx?
VBx was one of the four language implementations that were originally driving the design of the DLR, the other three being IronPython (from which the DLR was extracted in the first place), IronRuby and Managed JavaScript.
VBx was intended to be a dynamic version of Visual Basic.NET or a .NET version of Visual Basic 6, whichever way you want to look at it. It was primarily intended as a testbed for the flexibility of the DLR, secondarily as a testbed for a more dynamic version of VB.NET and tertiarily (is that a word?) as a scripting language for Silverlight. It has fulfilled its primary goal and the designers of VB.NET decided that they want to pursue goals two and three within the existing VB.NET language, rather than producing yet another slightly different incompatible version of VB. (You already have VB.NET, VB, VBA and VBScript.)
Managed JavaScript was also abandoned, the team was folded into the IE team and is responsible for the ECMAScript 5 engine in IE 9.
I'm already new in C++CLI , although I have been working on VB and C++ for a long time , but I need to start a projects on CLI using it's visual screens and easy codes (just in windows) , But I can't find any good Resource or book to start windows programming (I mean codes that you can give it to buttons or texts without using c++ classes) ,
Can I find any of them ?
thank you
I can suggest you 3 books ( I used them ):
Foundations of C++/CLI The Visual C++ Language for.NET 3.5
Pro Visual C++/CLI and the .NET 3.5 Platform
C++/CLI in Action
They are in order of difficulty.
The first and the 2nd are introductory and advance respectively.
The 3rd is great for advanced topics, like interop, mixed-mode coding etc..
Not sure what you have done in your work with C++ without classes, it is C with classes :). If you want to write Windows Program in C, Programming Windows, 5th Edition written by Charles Petzold could be a good start. Then you can decide which managed GUI to learn. Winform is mature with no future planned beyond .Net 4.0, while WPF is growing and is the main focus of Microsoft.
Modularity of basic programming first appeared with visual basic? True or False?
False, even GW Basic & Quick Basic which have appeared before visual basic have modularity.
False - Gordon Eubanks product: CBasic (written aboard USS George Washington) first available from IMSAI then later from Digital Research Corp after they bought it circa 1981 see this entry on wikipedia for more information.
QBasic (and presumably QuickBasic) had subroutines and functions which were (or at least could be) viewed and edited separately from the main program. While not file-level modularity, that does stand as one example.
I've seen examples of clean, modular BASIC code that predate VB. In general, you can use any programming approach with any syntax, although some syntaxes encourage a particular style. The BASIC language is free-form enough that the style it tends to encourage is "messy". Over the years Microsoft has made an effort to introduce features in VB that promote more structure.
Microsoft's BASIC PDS 7.1 compiler (Professional Development System) from 1989ish was very modular. You could link in C routines & Assembly routines (and Fortran IIRC). And the Basic itself allowed for calling other BASIC routines as sub-routines ect. I still use it today.
Amongst the swamp of documentation that is MSDN there is not an article to be found about the latest and greatest tools to be used in conjunction with Office 2007, specifically in the "VBA" department.
We've been using old school versions of Office for many years and had to use VBA. Upgrading to Office 2007 was a prospect for the PDF tools, however ye olde VBA seems to be the only choice of development within it.
Are there not newer .NET tools available? VB.NET, or C#.NET at least? If I have to declare and assign variables on separate lines using VBA one more time I think I may pluck my nose hairs out due to sheer frustration.
Thanks.
VSTO or Visual Studio Tools for Office
I put "better" in quotes because it's a qualitative question. I've been writing COM DLLs for a couple of years now and have only recently come upon, and successfully used, the standard DLL with Typelib concept.
Are there any compelling reasons to use COM DLLs instead of DLL+Typelib? Granted, you can't do DCOM with a DLL+Typelib, but is that the only reason?
EDIT I've written COM DLLs in Visual C/C++ 6, Compaq Visual Fortran, Delphi, Visual BASIC 6, ActiveState Perl and a few others. I've written standard DLLs in Visual C/C++ 6, Delphi, Ada and a few others. I've written typelibs for some of my own standard DLLs and also for third party DLLs. The question was originally written in the context of a Delphi DLL+Typelib reimplementation of a VB6 original.
TypeLib's are also important if you ever wish to migrate COM components to managed code in the future. Or have managed code interact with the COM components.
With a typelib there are lots of tools which will automagically translate your COM signatures into .Net interfaces and types. This can be done by hand but with a large project it's certainly a huge time saver.
It really depends on the clients of the component I would think.