How can i debug system.sevicemodel classes in my application?
It sounds like your interested in debugging the .NET framework code itself? If so, Microsoft has released source code to the public for much of the .NET framework.
However, to the best of my knowledge this does not include additions such WF, WPF and WCF (system.servicemodel), so you may be out of luck just yet. I could be wrong though, so it might worthwhile to review the following articles and see about setting up for debugging into .NET source to verify that these additions have not been added in the last year or so.
Check out ScottGu's announcement on releasing .NET source code to the public and how to get started. Be sure to follow some of the links in the announcement, specifically Shawn Burkes Configuring Visual Studio to Debug .NET Framework Source Code.
If you decide to head down this road, it might be worthwhile to read these two posts by John Robbins, Additional .NET Framework Source Code Debugging Tricks and an overview of the .NET Mass Downloader Utility.
If you had a more specific question in mind, please let us know!
Good Luck!
Z
Related
I have started writing tests for my project and am stuck at a point where my one object is dependant on another object. The test Framework I am using is MSTEST and I am using .Net 3.5 with visual Studio version 2008.
I would really appreciate, if you can share the best practices using this framework.
Also please let me know any better testing framework under the constraints mentioned above (it should be free to use).
Read up on Dependency Injection. It is a collection of code patterns that allow easier unit testing. I have just finished reading 'Dependency Injection in .NET' by Mark Seemann and it covers this problem in great depth. I would recommend it strongly.
Does VB.NET have anything similar to Java's JDK source code? When I used to work in Eclipse, I could right click and view the generated code, or "look under-the-hood" so to speak. I found this feature very helpful in understanding what was happening behind the scenes, and it helped me to write better, more simplified code.
I have so far been working with Visual Studio 2010's Object Browser, and I have also been looking at the generated designer files, but these often do not drill down far enough.
The best program to do this is called .NET Reflector and you can download it from here: http://www.red-gate.com/products/reflector/
It lets you see executables and DLL's under the hood
ScottGu has an old blog post about this:
http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx
You can also use the .NET Reflector to peek into the code for any .NET dll, but keep in mind it won't look like the code in Visual Studio :)
http://www.red-gate.com/products/reflector/
I own a copy of vb2005 professional.
I need to migrate a vb6 project to vb.net
Is there any difference in terms of effort to migrating to these
editions of vb.net
thanks
I think it's slightly easier to target the later versions. I believe the PowerPack 3.0 was added for Visual Studio 2005: it included extra support for emulating the VB6 Printer object and shape controls.
Anyone who's read my other answers about VB6 migration should stop reading now because I've said this before... but I think it's relevant, so I'll say it again anyway.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. People may advise you to just rewrite from scratch in .Net. Be cautious about this - you say your codebase is big, which is a danger sign for rewriting. Microsoft UK say
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
I'm rewriting a lot of VB6 currently and what I've found so far is that the previous developers had to use a lot of third party and custom modules to implement what they need when a lot of it has been included in the base class library for .Net since then.
From what I've seen there's no easy way to migrate from one to another. A lot of effort goes into these migrations. The best thing to consider is whether you want to try to go line by line or examine the code, document core functionality, evaluate how well the software has worked over it's lifetime and then engineer a new design.
That's what I've ended up doing because a line for line rewrite is nearly impossible and a large pain. Compiling libraries and modules into COM to bring the functionality into .Net applications is a lot of effort and kind of a "McGyver" approach. That's why I just documented everything well, understood the process, then wrote as .Net software.
Specifically, what functionality are you trying to maintain? Have you written in .Net before?
In my experience the "migrate" is really a rewrite so it doesn't make any difference what version of Visual Studio you use. I'd use the latest.
I noticed the other day that the Zune PC Software exposes a type library (ZuneCore.dll). It seems to be related to the WMPLib API in some way but I can't figure out how to use it either from VB6 or C#.
Has anybody tried this and had any luck?
Dave
May be an old question, but this link might help: http://zunelcd.codeplex.com/ If you download the source for this project one of the class libraries is a decent API for communicating with the Zune Software.
i just found out about this -> http://soapitstop.com/blogs/fleamarket/archive/2008/03/03/read-the-zune-collection-in-net-from-zune-s-own-api.aspx but it seems a bit outdated Initialize method now takes some parameters and i dont know what to put there!
Try adding a reference to it from a .NET project in Visual Studio. Perhaps this namespace will appear magically: MicrosoftZuneLibrary
I heard from a friend that Microsoft rewrote all the Windows Workflow Foundation (WF) again and changed everything was in .Net 3.5.
Is that true?
And what about what we learned about WF in 3.0 and 3.5?
According to this article:
http://visualstudiomagazine.com/articles/2009/01/01/windows-workflow-changes-direction.aspx
Windows Workflow Foundation 4.0 is a "bottom-up rewrite with entirely new thinking...WF 3.0/3.5 will remain part of the framework and will run side by side with WF 4.0. This lets you manage the transition at a time that fits your organization's broader goals."
...which is code for, "We know we just screwed up your programming model, but we have a long term strategy, so we hope you will forgive us."
The article goes on to say that
The gains are enormous: custom
activities take center stage, and
authoring them is much simpler;
workflows are entirely declarative;
and there are three workflow flow
styles that you can combine
seamlessly. It's possible that you
could see a 10-fold improvement in the
time required to create and debug
workflows, in addition to 10- to
100-fold runtime performance
improvements.
The change is not without its detractors. In this article at DotNetKicks, the author states that "Microsoft is seriously damaging the Dot Net developer community and adoption in the industry with these half baked product releases and abrupt about-faces after shipping."
Which is why I generally wait for the 2.0 or 3.0 version of Microsoft technologies, although I made an exception for ASP.NET MVC.
We found the workflow product to be difficult to wrap your head around when it came time to pass data in and out. Scott Allen had a series of articles that did a good job describing the process, but still this was not at an easy task.
That's what the word on the street is. And on the internet. 3.0 and 3.5 will be deprecated, but still available.
Is this change not in Visual Studio 2010 beta 1? Download it, find out, and tell Microsoft what you think of it.