|
|
-
Aug 7 was my last working day at Microsoft. I am on vacation now and will officially end my employment at MS on Aug 23. This means that there won't be any more Visual Studio blogs from me, unless I write one influenced by separation pangs.
It has been an interesting seven years. Not all of it was good but there have been more positive experiences than otherwise and I consider myself lucky to have gotten the opportunity to have been here. Meeting my wife here was the clear highlight of my stay. Meeting Bill Gates was next. Watching Steve Ballmer dance on Microsoft's 25th anniversary should probably count as the third.
All the best to you all for debugging all your apps, and I hope Visual Studio continues to enable you to do so in a user-friendly and robust manner. Let us face it, if your coding skills are anything like mine you spend 25% of your time in the editor and 75% in the debugger. The AppWizard? Nobody even cares about it unless it generates bad code :)
The title of this blog? A simple search should explain it. (Hint: Picard)
The next chapter of my life will be written at the Yale School of Management.
|
-
I have been reading several websites' coverage of Bill Gates' announcement to step down from the Chief Software Architect role in 2008. Most have focused on its impact on Microsoft, the technology industry, Wall Street and global health care (which stands to gain from the Gates Foundation).
But there is another segment for whom the world has changed significantly. For years I have been reading tech humour websites making fun of Bill Gates and the realization must now be dawning that soon there will be little new material for them. Yesterday someone at Slashdot forums pointed out that Slashdot's 'Borg Bill' gif might now need to be replaced. Without Bill, even the generic 'Microsoft jokes' would start lacking bite after a while, though Steve Ballmer still is well-known and colorful enough to sustain several Microsoft jokes on his own. Still, the curtain has probably come down on articles such as 'Evil Genius Gates Drops Windows 98 Into NYC Water Supply'
Who will provide the fodder for new material? Would Microsoft be able to retain its dominant position as the butt of technology jokes over the next decade? Time will tell. Here are some potential challengers:
- Sergey Brin and Larry Page - still too young, raw and well liked in the internet community. May I say also lacking the 'presence' that attracts humorists, though this could change.
- Larry Ellison - An excellent target for humorists thanks to his over the top persona. Still, makes it difficult to tell whether some stories are humor or plain facts. Probably peaked as a humor target with 'Diplomas are for losers'.
- Scott McNealy - Plethora of 'dot-not' and 'look-out' jokes have been insufficient to attain a leadership position in the tech humor segment. In the tech segment either, for that matter.
The situation looks grim for tech humor columnists. But the great thing about this industry is its ability to throw up a winner from apparently nowhere. There is no reason why some kid in some garage somewhere cannot rise to become the inspiration for all jokes in the days to come. Heck, with a bit of effort and enterprise, it could even be you. And needless to say, Microsoft will be around. And we are still the only company with the resources to build a Death Star.
|
-
Microsoft provides source access to some customers via its Code Center Premium (CCP) program. Not many people are aware that Visual Studio 2005 has integrated CCP support.
It is true! While debugging applications in VS you can download sources for system files from the code premium website provided you have CCP access. The prompting for the CCP card pin is handled in-session. The same license agreements apply.
This link gives you complete instructions on how to go about enabling and using this with VS 2005 - http://msdn2.microsoft.com/en-us/library/ms164729.aspx
Note that the CCP program is independent of Visual Studio and we are not involved in providing CCP source access. If you are interested in the program or have any complaints accessing the files you would need to contact the CCP team - http://www.microsoft.com/resources/sharedsource/ccp/premium.mspx
Regards,
Deep
|
-
We keep receiving questions about Visual Studio 2005's support for 64-bit. Here is a set of factoids that should help answer the most commonly enquired issues:
(a) There are two flavours of 64-bit - AMD64 or X64, and IA64. Windows 64-bit installs on both architectures.
(b) There is no 64-bit version of VS. Visual Studio 2005 is available only as a 32-bit app. However, you CAN install VS on a 64-bit OS and use it to create, launch and debug 64-bit apps.
(c) VS will install only on X64. The .Net Framework and the Debugger components install on IA64, allowing you to remotely launch and debug applications on IA64 from a VS IDE installed on another machine.
(d) VS installed on either 32-bit or 64-bit OS can create 32-bit or 64-bit applications, but of course the applications need the corresponding platform to execute.
(e) You need the Professional or Team System versions to build X64 (AMD64) apps.
(f) You need Team System to build IA64 apps. Pro does not support this. See http://msdn2.microsoft.com/en-us/library/hs24szh9(VS.80).aspx
(g) On a 32-bit OS, the 64-bit compilers will not be installed by default, you will need to go to custom setup and check the option.
How to create 64-bit apps
A managed project is automatically built according to the architecture selected => default C# project created on AMD64 will be AMD64, X86 on X86. The native one is always 32-bit by default.
To explicitly set a platform:
(1) open the solution explorer, select solution, right click->Configuration Manager.
(2) go to 'Active Solution Platform', click New.
(3) in the 'New Solution Platform' dialog that comes up select the new platform say Itanium. Set 'Copy Settings From' to 'Any CPU' which was the default setting in the 'Active Solution Platform'.
(4) click OK.
You will see that the platform has changed to Itanium in the config manager. Now when you build the solution, you will get an Itanium exe.
Follow the same process for X64, and to rebuild 32-bit apps from that solution.
|
-
It has been a while since I blogged. One reason is that not much is going on. Of course, at Microsoft that is a deceptive statement. By "not much" I mean that not much immediately impacting the customer is going on. We released VS 2005 and are starting work on the next version; however, before doing so we decided to take a break and improve our processes and infrastructure to make for a smoother release cycle than we had for VS 2005. A lot of dust that had gotten under the carpet is being cleaned, some processes and practices are getting discarded and new ones being brought in. It is amazing how "inefficiency" creeps in slowly over time; only when you step back and start asking "why the hell do we do this?" do you realize the baggage you have accumulated.
Additionally, I am getting married in March. Now you know where I spent the time I would use earlier for blogs and newsgroups. Given the time I used to hang out at the MS campus it is not overly surprising that my fiancee is also a Microsoftie. I have gotten her interested in Star Trek: The Next Generation and hope to also develop her interest in Warcraft. In turn, she has cured me of my habit of spending weekends in the office.
I went climbing Mt Pilchuck with some friends this weekend. Just so you know, it is not an easy hike this time of year with all the snow. Heck, it is not even an easy drive to get to the mountain. A couple of cars got stuck in the snow and my friends and I helped push one poor guy's SUV out. The fun part was that when the tires started rolling they sprayed snow all over Richard's trousers.
Finally, I discovered "The Picard Song" in January. Apparently it has been out since 2003 only nobody told me. It is quite addictive and I would recommend that you give it a hearing: http://thepicardsong.ytmnd.com/
Regards,
Deep
|
-
Hi!
A customer emailed me with the feedback that my sample code with C++ Exe calling C# Dll does not build with VS 2003.
I investigated; the reason is that in VS 2003 the tlb exposes the namespace in lowercase as csdll instead of CSDll. The fix for this is to update the C++ code to use 'csdll'.
Alternately, you can add a 'no_namespace' to the #import tlb line in the .cpp file and then call all CSDll objects without using the namespace.
Regards,
D.V.
|
-
Hi!
The Debugger team is having a Chat this Thursday (Dec 15) from 1:00 to 2:00 Pacific Time. If you have any problems with the debugger, this would be a great opportunity to ask questions and get live responses.
The Chat homepage is http://msdn.microsoft.com/chats/
Regards,
D.V.
|
-
Hi!
Recently, downloading symbols for microsoft shipped binaries using the Microsoft symbol server (http://msdl.microsoft.com/download/symbols) broke for Visual Studio 2003 users. Microsoft has disabled downloading symbols using older versions of symsrv.dll for compatibility reasons.
To resolve this, you need to update the symsrv.dll on your machine with a newer version. Symsrv.dll is a component that is updated periodically, and the latest version can be obtained from the debugging tools for windows package at http://www.microsoft.com/whdc/devtools/debugging/default.mspx.
Simply replace your Visual Studio symsrv.dll (located next to devenv.exe) with the one from the debugging tools package, and everything should start working fine.
Regards,
D.V.
|
-
In VS 2003 & earlier breakpoints were bound based only on file name, so if the project system found another file with the same name we would bind the bp there. This was a source of a lot of annoyances since files like Class1.cs are everywhere, so in VS 2005 we have added support for source checksums in the compilers, and the debugger looks at these to verify a file.
If we find the correct file, your debugging experience goes exactly as earlier, but some customers have had problems working with sources out of sync with the binaries they are debugging (people may want to try this if the exactly matching sources are inaccessible for some reason).
If you start debugging with mismatching sources, you get a nice dialog informing you that the source is not matching, you can choose to continue to use it anyway. In this case, for the rest of the debugging session, you will not get prompted again, and if you set breakpoints in the file, they will bind.
If you already had set breakpoints before starting to debug, those bp's may not bind. In that case, you can right click on the breakpoint, click the "Location" menu item, and in the "File Breakpoint" dialog check the "Allow source code to be different from the original version" checkbox. Note that only file breakpoints are affected by checksums.
Alternately, you can turn off verifying checksums altogether from Tools->Options->Debugging->General->Require source files to exactly match the original version.
|
-
Interop - calling native (C++) code from managed (C#, VB, J#, MC++) and vice versa - can be very useful if you are trying to extend your libraries without porting existing code. However, it can often be confusing for a newbie to figure out how to set this up.
There are several ways in which you could accomplish this.
(a) Using COM-Interop
(b) Using imports/pinvoke (explicit method calls)
(c) IJW and MC++ apps : MC++ & IJW apps can freely call back and forth to each other.
(d) Hosting. This is rare, but the CLR can be hosted by an unmanaged app which means that the runtime invokes a bunch of hosting callbacks.
Here is how (a) works:
For Native Exe->Managed Dll
(a) define C# (VB, J#) class with a public interface, and build the file as dll
(b) run regasm on the dll to create the tlb file
(c) define C++ code which #imports the type library and creates the C# dll’s interface object using CoCreateInstance() and then calls methods through that.
For managed client->Native Dll
(a) create C++ Dll
(b) Create managed exe, add a reference to the Native COM Dll
(c) Create the Com object and call the methods.
Here are code samples for the cases
Native Exe calling Managed Dll
Dll code is (filename CSDll.cs)
using System;
using System.Collections.Generic;
using System.Text;
namespace CSDll
{
using System;
[System.Runtime.InteropServices.Guid("D4660088-308E-49fb-AB1A-77224F3FF851")]
public interface IMyManagedInterface
{
int factorial(int arg);
}
/// <summary>
/// Summary description for Class1.
/// </summary>
[System.Runtime.InteropServices.Guid("46A951AC-C2D9-48e0-97BE-91F3C9E7B065")]
public class Class1 : IMyManagedInterface
{
public Class1()
{
}
public int factorial(int arg)
{
int result;
if (arg == 1)
{
result = arg;
}
else
{
result = arg * factorial(arg - 1);
}
return result;
}
}
}
Compile this with "csc /debug /t:library csdll.cs" to build a dll with symbol info.
Now run "regasm csdll.dll /tlb:csdll.tlb" to create the type library
C++ code is as (filename cppexe.cpp)
#include "windows.h"
#include <stdio.h>
#import "CSDll.tlb" named_guids
int main(int argc, char* argv[])
{
HRESULT hRes = S_OK;
CoInitialize(NULL);
CSDll::IMyManagedInterface *pManagedInterface = NULL;
hRes = CoCreateInstance(CSDll::CLSID_Class1, NULL, CLSCTX_INPROC_SERVER,
CSDll::IID_IMyManagedInterface, reinterpret_cast<void**> (&pManagedInterface));
if (S_OK == hRes)
{
long retVal =0;
hRes = pManagedInterface->raw_factorial(4, &retVal);
printf("The value returned by the dll is %ld\n",retVal);
pManagedInterface->Release();
}
CoUninitialize();
return 0;
}
Build this with "cl /Zi cppexe.cpp" -> when you run the exe it should print the value 24.
To debug this app, open the exe as a project in Visual Studio. Then go to project->properties->configuration prop->debugging and set debugger type to Mixed. Now when you debug, you should be able to step into the managed dll code from the calling C++ exe.
Managed Exe calling Native Dll
(a) Create an Atl COM Dll from wizard say Atl Dll
(b) Add an ATL Simple Object AtlObj
(c) Add a method to AtlObj say factorial(), you will need to add it to the .idl file to expose it from the COM object
(d) Create a C# console app
(e) project->right click->Add Reference
(f) In the add reference dialog, select the COM tab, find your COM component and add the reference to it
(g) You can now create the AtlObj object as of any other class and call its methods.
You can also accomplish this without using COM by simply using exports/imports.
Managed Exe calling Native Dll using import
(a) Create a Win32 Dll that exports symbols, you can do this from the wizard, just make sure the "export symbols" checkbox is checked.
(b) You need to put extern "C" {} around the definition & declaration of the exported function say fnWin32Dll()
(b) Now create your C# Exe, add using System.Runtime.InteropServices;
(c) add code
[[DllImport("Win32 Dll.dll")]
public static extern int fnWin32Dll(); ' this is the C++ function exposed by the dll
(d) Now you can just call the function in your code
int var = fnWin32Dll();
Note that your C# Exe needs to be able to find the Dll. You can copy the Dll next to the C# Exe and it will run just fine.
These are the most common ways of making cross-language calls, I will follow up later with explanations and examples of the other ways you can make these calls.
|
-
Many people have used and liked the new visualizers in Whidbey. They really are a powerful data viewing tool, especially with the functionality of supporting custom visualizers. While the help documentation for writing your own visualizers is getting finalized, I thought I would provide a quick how-to for this. To create a custom visualizer in C#, create a C# dll with this code using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;
using Microsoft.VisualStudio.DebuggerVisualizers;
using System.Diagnostics; [assembly: DebuggerVisualizer(typeof(CS_Visualizer.Class1), typeof(VisualizerObjectSource),
Description = "Test Visualizer",
Target = typeof(System.String))] [assembly: DebuggerVisualizer(typeof(CS_Visualizer.Class1), typeof(VisualizerObjectSource),
Description = "Test Visualizer",
Target = typeof(System.Int32))] namespace CS_Visualizer
{
public class Class1 : Microsoft.VisualStudio.DebuggerVisualizers.DialogDebuggerVisualizer
{
protected override void Show(Microsoft.VisualStudio.DebuggerVisualizers.IDialogVisualizerService windowService, Microsoft.VisualStudio.DebuggerVisualizers.IVisualizerObjectProvider objectProvider)
{
if (windowService != null)
{
object data = (object)objectProvider.GetObject(); Form displayForm = new Form();
displayForm.Text = data.ToString();
windowService.ShowDialog(displayForm);
}
}
}
} You will need to add references to System.Windows.Forms & Microsoft.VisualStudio.DebuggerVisualizers. Try this code for VB <Assembly: DebuggerVisualizer(GetType(Class1), GetType(Microsoft.VisualStudio.DebuggerVisualizers.VisualizerObjectSource), Description:="My Test Integer Visualizer", Target:=GetType(Integer))> <Assembly: DebuggerVisualizer(GetType(Class1), GetType(Microsoft.VisualStudio.DebuggerVisualizers.VisualizerObjectSource), Description:="My Test String Visualizer", Target:=GetType(System.String))> Public Class Class1
Inherits Microsoft.VisualStudio.DebuggerVisualizers.DialogDebuggerVisualizer Protected Overrides Sub Show(ByVal windowService As Microsoft.VisualStudio.DebuggerVisualizers.IDialogVisualizerService, ByVal objectProvider As Microsoft.VisualStudio.DebuggerVisualizers.IVisualizerObjectProvider)
If windowService IsNot Nothing Then
Dim data = objectProvider.GetObject
Dim displayForm As New Windows.Forms.Form
displayForm.Text = data.ToString
windowService.ShowDialog(displayForm)
End If
End Sub
End Class The dll built needs to be copied to either your My Documents\Visual Studio 2005\Visualizers or Common7\packages\debugger\visualizers folder. The latter should have write permission only for admins since it should be under the Program Files folder (by default). After this, when you view an object of the types specified (integer & string here) in the debugger, you will see the visualizer hourglass, and on clicking it, a form will come up showing the value. You can easily tweak this code sample for other types, note that - only one dll can handle multiple data types, we are handling two types here
- though here we are just drawing a winform, the code to display the visualizer can be of any complexity.
- your data type needs to be serializable. I used basic data types here, if you want to create visualizers for your custom classes with multiple fields you will of course need to be able to pass it to Show() for displaying.
Happy visualizing!
|
-
Daniel Spalding, our Dev Lead in the VC++ linker team, retired last friday after 18 yrs at Microsoft. In a sense it is an end of an era since he has been around, like, forever, and it is difficult to visualize a linker team w/o him. Dan was one of the devs who implemented the "detect which files have been changed since last build and build only those next time" optimization back in 1994. On a lighter note, I think he was the last guy in our building who came to work in a Ferrari - I think he had 3 of them. No more Ferraris in the bldg 41 parking lot!
|
-
Scott & I finished our "Inline Version Control" add-in for the app week, and I think for a week's work we did a fairly good job. I was rather surprised and impressed with the apps other teams came up with, and we are going to know the best app in a while (the managers pick this). We definitely want to release it to the community, but it is still hazy when we will do so. We might do this with the Beta2 release, or we might have to wait till RTM. I think for community release we definitely want to make sure the code is well organized and documented and promotes good coding practices. This was the first time we used extreme programming in our app weeks, this was in fact the first app week designed to allow this. It was an interesting experience. What went really well was that the two of us could bounce ideas off each other all the time, and there was no integration cycle - the whole app was designed and implemented on one machine, and so we did not have to worry about changing assumptions about public interfaces. We should extend this to n developers sitting in a conference room and coding a component on a single machine with the code projected on the wall! What we really managed to avoid were silly bugs, when you have two people looking at a code, you are far less likely to call functions incorrectly and the like.
|
-
One bloggable event happening right now is that we in the C# PU are once again planning an App Week. For those who are not aware, an app week is where we get together, form teams, and develop customer scenario applications with our product to find bugs and more particularly integration issues that we typically will not catch in day-to-day testing. There are several teams of varied sizes this time, and I got paired with Scott Nonnenberg. There are just the two of us in our team, which we decided to vaingloriously name "SuperNerds of Redmond" or SNOR. Also, this time, since we have so much to do to get the product out the door in time, the app week will last only a week. (don't go D'oh, despite the singular name, app weeks typically last more than a week, most likely two). Typically the apps are not something that we expect to release to anyone, they are just to find bugs and let us play with different features of the product other than our own, but this time we are hoping to come up with something that people might actually use. Scott & I looked at customer suggestions that came in after the beta, and are leaning towards writing an add-in that allows you to restore earlier versions of your source file. There are a few other suggestions, some rather trivial, some too complicated for 2 people to complete in 5 (+2 weekend!) days. If you have a suggestion for a nifty little feature you found yourself wishing for as you used Visual Studio, we both would be happy to hear it. Note that this has to be a feature related to the C# or Debugger experience.
|
-
One of my goals for this year has been to post regular blogs. The problem I keep running into is thinking up topics to post that are not an insult to your intelligence - e.g. describing stuff that is already mentioned in MSDN, and that, if you have taken the trouble to browse to http://weblogs.asp.net, you probably know already. Sure, I could describe what I do at work, but people are unlikely to be impressed by (or interested in) regular stuff and the non-regular stuff could get me into trouble if shared. For example, we in the developer division recently did a security review where we went over the product looking for potential & real security issues. (BTW, I don't think I am divulging any trade secrets if I mention that a lot of our security training comes from Writing Secure Code , also consider this a shameless plug, since the author is a MS guy and hangs out in my building's cafeteria to boot.) This review was in my opinion a lot more in-depth than we have done earlier (I guess we are more experienced now, practice improves form), and we came up with some interesting attack surfaces that we hadn't thought of earlier. This might seem like a teaser but I cannot blog the techniques we used since that might facilitate hackers, though I would suspect at least some of the hackers out there (the l337 u83rh4x0rz)* know at least some of these techniques and have indeed tried them against our software. Ergo, no real bloggable content over several weeks of work. Be that as it may, I really enjoy having people ask questions via the blog email link, and I try to answer them the best I can. If you have any discussion topic, feel welcome to suggest it. In the meantime if I cannot think of anything significant, I will try to keep in touch with little tidbits. Have a great 2005! * means elite uber-hackers
|
|
|
|
