In Visual Studio 2005, ASP.Net web applications are not projects any more – they cannot be found in the “New Project” dialog box. Instead it stands on its own in the File menu, as a “New Web Site”.
Archive for Microsoft
Windows shared folders uses NetBIOS over TCP/IP using these ports:
* UDP 137: NetBIOS name service
* UDP 138: NetBIOS datagram service
* TCP 139: NetBIOS session service
Need to try out if enabling these ports on a firewalled machine actually allows FileSharing.
When running CF apps in debug mode using VS2005, I could always see messages like:
A first chance exception of type "System.FileNotFoundException" occured in mscorlib.dll
Why are the core libraries throwing exceptions and how to avoid them? It turns out that first chance exceptions occur whenever exceptions are thrown (duh). If they are caught (with a try/catch clause) the application continues to run normally, but the debugger will print that line into the output. If the exception is uncaught, the debugger is notified again and the application breaks into debug mode. This is known as “second chance exception”. So far from what I see, it means you cannot avoid getting the first chance exceptions.
According to the links below, VS can be configured to react differently at the chance exceptions. Different actions may be taken for different exceptions or exception groups (exceptions hierarchy).
For introduction sake, the Microsoft Enterprise Library is a set of open-source libraries that developers can freely use, extend, and modify to build better “enterprise” applications . (weird isn’t it? Microsoft — Open Source, they probably realized that few MS developers really knew how to code properly) The library contains a suite of classes (known as application blocks) for the following areas:
- Data Access- Cryptography
- Exception Handling
- Logging and Instrumentation
The DAAB is one of the blocks, and supposedly simplify database code by abstracting it from
SqlConnection myConnection = new SqlConnection("..");
SqlCommand myCommand = new SqlCommand("..", myConnection);
SqlDataReader reader = myCommand.ExecuteReader();
Database db = DatabaseFactory.CreateDatabase();
IDataReader reader = db.ExecuteReader(CommandType.Text, "..");
Not much of a difference, the important thing is that the implementation is now more database independant, and configuration of using which database are stored in complex XML files (using the Configuration Application Block).
The old syntax was inherited all the way from DAO days, and I’m expecting they’ll be shifting this Object Oriented Enterprise way like DAAB into Vista next time. Performance-wise, this blog says DAAB vs DataAdapters give identical results … anyone else ran different tests?
Java developers have absolutely no problem with this, because from Day one they were taught to use DriverManager.getConnection() and the Connection, Statement, ResultSet interface instead of ODBCResultSet or OracleResultSet.? 🙂
Connection conn = DriverManager.getConnection("...");
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("...");
 http://www.alternex.net/philippe/PermaL … e75d1.aspx
Today’s topic is on WinFX, the “core” managed API in the to-be-released Windows Vista. WinFX consists of 3 frameworks :
* Windows Presentation Foundation (WPF/Avalon) – GUI APIs
* Windows Communication Foundation (WCF/Indigo) – Messaging API for inter-process / inter-machine
* Windows Workflow Foundation (WF)
WPF is straightfoward that it encompasses all the Windows Forms and drawing API. WCF is more interesting because the new API uses an SOA to locate both local or remote processes in the same way and communicate using SOAP. From  inter-WCF communcations will be performed using an optimized binary SOAP format, while non WCF will be standard SOAP. Hopefully the non-WCF protocol will be well-documented so that other technologies can communicate with WCF processes easily. I can forsee projects starting to build non-Microsoft adapters to communicate in WCF SOAP formats.
 shows some seasoned Windows Developers arguing that WinFX will never take over Win32, since all managed calls have to end up calling some Win32 functions. However the author explains that although WinFX functions are expected to be just wrappers to Win32 DLLs, the situation may be reversed in the future. Core Win32 DLLs now do little but to call pentium instructions to perform their task. The situation may later be reversed such that Win32 dlls become wrappers to WinFX functions as Win32 reduce in favour of WinFX. The same situation has happened to Win32 and Win16, where Win32 now takes over Win16 as the core API for the OS.
From what happened between Win32 and Win16, I believe that the same will happen to WinFX and Win32, as Win32 gets phased out. In the end, does that mean that future Java bytecode will be interpreted into WinFX calls by the Java interpreter and then interpreted into CIL by WinFX and then interpreted by the CLR before becoming machine code? Hmm…