MOST COMMON DOUBTS ABOUT MFC/.NET Technologies

 This is an abstract taken from here. I hope this will be enough to clear all the doubts regarding MFC /.Net Technologies for the starters.

1. What are the future plans for MFC, ATL in the .NET world? Are MFC and ATL’s days numbered?

This is a very popular question. I’m sure you’re aware that there are literally millions of Visual C++ developers who use, extend, and incorporate both MFC and ATL into their applications. In fact, as many as 75% of all Visual C++ developers use MFC. Microsoft considers these libraries to be extremely robust and mature – they’ve been around for a long time, have been used as the infrastructure for hundreds of thousands of applications, and have grown over the years with countless updates and extensions. They have been very successful. Our focus is starting to shift to .NET, but MFC and ATL will each be continually updated in order to maintain sync with operating system features, and will be maintained into the foreseeable future. Backwards compatibility is always an issue with libraries like these, and as computing environments and requirements change it becomes more and more difficult to extend an older technology and still retain robustness. The time has come for us to introduce a newer technology with a renewed lifespan, and the C++ team is committed to making the transition as easy and comfortable as possible for MFC developers. With Visual C++ .NET you can continue to use MFC and ATL where it makes sense, and begin the transition to the .NET Framework at a pace you set.

2. Where do these libraries fit into the .NET vision?

Today MFC and ATL fill roles that aren’t yet fully realized in .NET. .NET, with all of its thousands of classes in the framework library, doesn’t provide application framework functionality similar to that provided by MFC. Developers need to be aware of their options – both managed and unmanaged, and choose carefully the technology most suited for the task. Visual C++ developers are typically very advanced, and have for years been accustomed to choosing appropriate technologies for their applications — so this should be nothing new. With .NET, VC++ developers have the distinct advantage of being able to seamlessly integrate existing unmanaged code with newer managed code and data without the headaches of losing backwards compatibility or learning a new language. Managed extensions for C++ make sense for progressing applications forward, and they’re easy to use.

3. How long will these libraries be supported?

We have no plans to stop supporting any library shipping with Visual C++. All of the VC++ libraries have extremely high usage in real-world code, and Microsoft isn’t about to ignore this fact. We’ll continue to refine existing libraries, and have plans to introduce new libraries as technology evolves.

4. What are the new version numbers and DLL names for MFC and ATL?

MFC version 7.0 – MFC70.DLL
ATL version 7.0 – ATL70.DLL

Note the changes from the DLL names in 6.0 – we broke binary compatibility in order to make some key refinements to the libraries themselves. But your code will recompile against the new versions just fine.

5. Once .NET becomes established on every PC running Windows, will there be any reason at all to write C++ or MFC apps?

Assuming feature parity between .NET and MFC, a developer might choose MFC if there were a compelling need to write purely unmanaged code. Developers may choose to use C++ to target .NET because of the powerful C++ language features not found elsewhere, like templates, and the quality of code generated by the compiler. Visual C++ .NET is the only .NET compiler that generates highly optimized MSIL, and it is the only compiler that can generate an assembly image containing both managed and unmanaged code. Developers should choose C++ when they need unbounded flexibility and control.

6. Why would a developer wish to use MFC instead of Windows Forms, and why Windows Forms instead of MFC?

Windows Forms are a technology that do not yet provide the command-routing and document-view infrastructure found in MFC. Today, choosing Windows Forms is similar to choosing Visual Basic 6.0 in place of MFC. Each offer distinct advantages – the developer or architect must determine what priorities are relevant. The really sweet thing about C++ is that you can choose MFC and at the same time incorporate .NET technology where it makes sense. One reason we did this was so it would be dead-simple to extend existing applications without requiring them to be rewritten. A second reason is to enable the C++ developer to self-pace their adoption of .NET technology. We knew the C++ developer wouldn’t be interested in a technology that forced abandonment of their existing skills or code.

7. Will MS be writing any of their apps in MFC or will they start moving to C# and Windows Forms?

A majority of Microsoft applications are already incorporating .NET technology, using not only C#, but also C++ and Visual Basic .NET. There may well be less MFC development done at Microsoft going forward, but because MFC is integral to so many existing applications – our own and 3rd party — it will continue to be a viable and supported framework for some time to come.

8. What is the future of WTL? Will it be made an official framework?

We don’t have specific plans for WTL. However, we are rather stunned by its growing popularity and are keeping a close watch. It is not a topic we’re ignoring internally.

9. MFC and ATL had some changes under the hood, but no major facelift and only a handful of new classes. What were the reasons for this?

As I’ve said, these are mature libraries that accomplish their objectives well. Our intention is to enhance them to keep pace with operating system features, to refine them where it makes sense, and maintain backwards compatibility. The updates we made for Visual C++ .NET reflect this positioning, and comprise a slew of refinements that make these libraries easier and safer to use, while adding support for Windows 2000 and XP.

10. Can you give us a brief rundown of the new features in Visual C++?

The list is actually quite long – a full enumeration of new features exists in the product documentation under “What’s New in Visual C++ .NET”. I have several favorites that I’ve been using in my own code. For the first time, it is now easy to use both MFC and ATL in a single application – the compiler will no longer complain about conflicting header definitions. Both libraries now share CString, and have in common several of the other non CObject derived classes. This feature alone factors out a lot of potential for duplicated effort in code, and can lead to a much more elegant implementation. It’s about time we did this, and it just makes sense. The STL library has been entirely overhauled – with more readable source code, a faster and standards-compliant implementation, fixes to all known major issues like threading and cross-DLL usage, and, at long last, all new documentation. And of course, the compiler itself has loads of new options and features, including whole-program optimization, code security features including support for runtime buffer-overrun checking, and managed-code generation.

11. Can we expect MFC and ATL/WTL to be extended in the near future to cover new features and controls in W2K, XP and CE 2002? Will MFC try to emulate some of the new components in .NET?

Yes, MFC and ATL will continue to enable developers to target the newest features of Windows. If you want to include new .NET features in your MFC application you can do this directly – there’s no need for MFC emulation of the feature.

12. Are there any tools to help developers move from MFC/ATL to .NET?

Beyond the /CLR switch of the C++ compiler, no. Should there be? What would you like them to do? How should they work? We’re very interested in this and are keen to have feedback about the importance of such a tool.

13. Can I still use MFC and my old MFC components in .NET?

Yes. It is easy to wrap or extend existing C++ components so they are callable from .NET – by any language. This is much simpler than it used to be with COM and ActiveX. Simply add a keyword to mark an object as a .NET reference-type, and compile with /CLR. No IDL, no reference counting, no registration code. Code it and use it – very simple.

14. Will MFC and ATL be extended to cover XML Web Services?

MFC and ATL already have the capability to consume and expose XML Web Services in Visual C++ .NET, both with managed and unmanaged code.

15. The various wizards had some annoyances, such as not handling derived classes very well, or being too restrictive. How have Microsoft addressed this in Visual Studio .NET?

One way we’ve addressed this in Visual Studio .NET is by exposing, for the first time, an extremely extensive automation interface enabling developers and third-parties to create their own add-in applications. If a wizard or feature doesn’t do what you want it to, you can write your own. With VS.NET automation, you can plug into the IDE at the same level of integration as any of Microsoft’s features. If you’re a member of the VSIP program you can even integrate new languages and compilers with the IDE.

16. Will MFC be ported to managed code to allow it to be used in Managed C++

We won’t likely port MFC to be a fully managed library. But it is entirely feasible to extend your own MFC applications with managed code – without leaving C++.

17. Will there be a MFC-like framework for .NET?

The .NET framework will continue to evolve and will likely add capabilities that are found in MFC. The C++ team is driving for this internally – we want .NET to be a compelling and comfortable place for C++ developers. We’ll achieve this is in a couple of ways. First, we’ll continue to make it easy to use the .NET Framework in C++ code. Secondly, we’ll ensure that there are compelling reasons to continue using C++ – by enabling C++ to achieve a level of flexibility and control on .NET not found in other languages.

18. What compelling reasons are there to upgrade to Visual Studio .NET if I have no intention of writing managed code?

Every aspect of the product has updates – the IDE, the debugger, the compiler, the libraries. As I mentioned before, the compiler alone offers the several new optimization and code-security features that increase the robustness of your applications. Across the board we’ve overhauled features like Intellisense, debugging scenarios, even the warning and error messages you get building code.

Bottom line: building existing code with Visual Studio .NET will result in faster, more robust software with lots of new potential to expand the capabilities of your application with emerging technology.

19. Can I use Visual C++ .NET to develop traditional MFC apps?

Of course! No one is forcing VC++ developers to swallow .NET whole – in fact, managed-extensions aside, the majority of features we’ve added this iteration are geared at unmanaged code development. MFC development is better than ever with refined IDE integration, compile-time type-checking for message maps, ATL support, and new classes to access new OS features.

20. What’s your favorite Website?

CodeProject.com. You guys rock.

Redistribution of mfc70.dll files

Is there anyone who knows which mfc70.dll files I need
to redistribute with my program? ( I don´t want to link
statically ) And is it safe to overwrite clients mfc70.dll if
the case is that is allready installed on their computer?

The following might be more than you are asking for…but it might be helpful…

You can link the MFC dll statically as suggested but I do not like this thing very much since it blows up your application file etc. Usually I suggest building a custom-based installation file (you can use InstallShield for example) which installs your application and all necessary dll’s on the target system even with version checking…

Updating system dll’s is always a tricky thing to do. But nevertheless sometimes your software requires changing some of the system dll’s.

In this context it is important to install a newer version of a file and not an older one. For example, you will want to install a newer version of a system DLL on top of an older version, but not an older version on top of a newer version. Typically, version checking is the responsibility of the setup program. If you write your own custom setup program, you must manually check the version when installing redistributable files.

First of all you need to find out which dll’s needs to be redistributed to make sure that your application will run independent of the installed dll’s on the target system. For an overview of the dependicies of your application you have two possibilities:

1. Use the ‘Dependency Walker’ (depends.exe)

2. Use ‘Dumpbin’ (dumpbin.exe) with the parameter /DEPENDENTS

Both methods will show you a list of dll’s that are linked to your application – either statically or dynamically. To find out which dll’s are dynamically loaded you need to use the profiling feature of the ‘Dependeny Walker’.

Be always aware that a dll might have dependicies to other dll’s or even a version of a specific dll. If you have installed your application on a target system and it won’t run you can again use the ‘Dependency Walker’. Run it on the target machine and it will report which dll’s are either missing or present with an incorrect version. Dll’s should always overwrite the existing dll’s to avoid multiple instances of the dll on the system.

If your application needs MFC support and you don’t want to link it statically to your application (which I normally not recommend) you need to distribute it as well. MFC dll’s are shared components therefore they will be placed within the system directory. You can get the system directory by a call to the API function

Code:

 

UINT GetSystemDirectory(LPTSTR lpBuffer, UINT uSize)

Again, installations within the system directory needs to be done carefully. NEVER overwrite a newer dll since other applications may rely on the specific version. To check the version of a dll Windows provides several API functions (Version API).

Your setup application needs to place needed files in the correct locations and prompt the user if the setup application notice some significantly difference like different language version or you try to overwrite a newer file with the older one. Therefore you will need some information on those files like name and location of the source and destination file and much more important the sharing status of the file (only used by one application or shared between multiple applications).

Regarding the location and the sharing status you can use the function

Code:

 

DWORD VerFindFile(DWORD  dwFlags,

                  LPTSTR szFileName,

                  LPTSTR szWinDir,

                  LPTSTR szAppDir,

                  LPTSTR szCurDir,

                  PUINT  lpuCurDirLen,

                  LPTSTR szDestDir,

                  PUINT  lpuDestDirLen)

This function will return several error codes whether the file is currently used by the system etc. Depending on the error code your setup program must react in a proper way.

To install the source file you should use the function

Code:

 

DWORD VerInstallFile(DWORD  uFlags,

                     LPTSTR szSrcFileName,

                     LPTSTR szDestFileName,

                     LPTSTR szSrcDir,

                     LPTSTR szDestDir,

                     LPTSTR szCurDir,

                     LPTSTR szTmpFile,

                     PUINT  lpuTmpFileLen)

since it will do some work for you. It copies the source file to a temporary file within the destination directory – if necessary it will expand a compressed file. After that an automatic comparison of the version information of the temporary and the destination file will be done. Again, your setup program should react to the returned error codes in a proper way. This function can be called multiple times with different flags. For example, if the first call returned an error indicating a version conflict you can force the installation disregarding the conflict by calling this function again with the ‘VIFF_FORCEINSTALL’ flag. On the other side your setup program needs to take care of the created temporary file by deleting them properly.

To retrieve the version information your setup program can use the following functions…

Code:

 

DWORD GetFileVersionInfoSize(LPTSTR lptstrFilename, LPDWORD lpdwHandle)

 

BOOL GetFileVersionInfo(LPTSTR lptstrFilename,

                        DWORD  dwHandle,

                        DWORD  dwLen,

                        LPVOID lpData)

 

BOOL VerQueryValue(const LPVOID pBlock,

                   LPTSTR       lpSubBlock,

                   LPVOID       *lplpBuffer,

                   PUINT        puLen)

 

DWORD VerLanguageName(DWORD wLang, LPTSTR szLang, DWORD nSize)

‘GetFileVersionInfoSize()’ returns the size of the version information. ‘GetFileVersionInfo()’ uses information retrieved by ‘GetFileVersionInfoSize()’ to retrieve a structure that contains the version information. ‘VerQueryValue()’ retrieves a specific member from that structure. Your setup program needs to call those function depending on the error code returned by e.g. ‘VerInstallFile()’.


Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: