|
|
You should not use that unless you're running on a server or the machine has the SMTP Virtual Server installed with CDO configured correctly. SmtpMail uses a CDO server (CDO is a COM wrapper for MAPI, basically) and, thus, a CDO server must be installed. Currently Microsoft Exchange and Microsoft SMTP Virtual Services are two such CDO servers. Neither of those will run on Windows 9x/Me.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Heath Stewart wrote:
SmtpMail uses a CDO server (CDO is a COM wrapper for MAPI, basically) and, thus, a CDO server must be installed.
I didn't know that. Sorry! 
But, if my app will run only on Win2K and WinXP, is it ok? even on a Windows Forms application?
Thanks!
-- LuisR
Luis Alonso Ramos
Intelectix - Chihuahua, Mexico
Not much here: My CP Blog!
|
|
|
|
|
Luis Alonso Ramos wrote:
But, if my app will run only on Win2K and WinXP, is it ok?
You need to make sure that Exchange/SMTP Virtual Server is configured right. If you need to forward to an external SMTP server, for example, you need to configure your local SMTP service to forward and make sure the other end accepts forwards for your host. There's a lot to consider when using an SMTP server.
Out of the box it may work for any code that uses SmtpMail but it really depends on your setup, which is outside the scope of this forum.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Do not use SmtpMail for the reasons I gave to the person who first replied to your question. It relies on CDO which is not available on every machine and you're application would not be portable.
Instead - if you'd have clicked on "Search comments" to search for similar questions and answers first - you should've found many alternatives, such as connecting to the SMTP server yourself and sending mail. It's actually quite easy.Sending SMTP yourself is actually very easy and many of the articles above will show you how. It's a matter of connecting to the domain's SMTP server (that's what the MX record is for) on port 25 using a TcpClient connection and sending commands and data in a particular sequence.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
If you set the font to "MS Gothic" and enter the text by hold down ALT and type "127" with the numeric keypad (not the keys along the top of the keyboard) and then release the ALT key, the caret postion is not moved forward, where as in MS WORD, NOTE PAD, TEXT PAD the caret position moves forwards.
Similarily for ALT + "128", ALT + "65376", ALT + "65440", the result for the richTextBox differs from others.
1.I need info regarding the reasons for showing different output for the same kind of input, among the editors.
2.Can RichTextBox editor output be made same as that of NotePad?
|
|
|
|
|
Hi,
A aprogram changes the resolution to 800x600 when starts, then changes it back 1024x800 by the exit (using [DllImport("user32.dll")]). The problem is that all desktop files and shortcuts change their locations (appear in new positions within the 800x600 area).
Is there any way to switch resolution to lower and back with desktop files remain in original positions?
If you know any trick please help.
Thanks
|
|
|
|
|
The trick is to NOT do it. There is no way to change the screen resolution without affecting the desktop, unless you want to write all your window code using DirectX (Don't even think about it!)
You shouldn't be changing the display resolution anyway. Changing system-wide settings is extremely poor practice, considering your sharing the system with other applications. What you do in your application may affect the operation of other apps. Besides, when your app crashes (don't tell me it won't!), how is it going to set the resolution back to what it was?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Strongly agree with you.
This posting is provided "AS IS" with no warranties, and confers no rights.
Alex Korchemniy
|
|
|
|
|
Is there any suggestion on how to make the program portable through different resolution settings without letting the user know?
|
|
|
|
|
To get your application to support multiple screen sizes you need to utilize Docking and Anchor features. 
Of course there's a lot more to it... but this is the start.
This posting is provided "AS IS" with no warranties, and confers no rights.
Alex Korchemniy
|
|
|
|
|
Does anybody know how to create an automation server in C#? I only know how in MFC, but could not find any articles or sample code in C#. All I am looking for is to have my .net application to be launched by another desktop application. Any suggestions would be appreciated.
|
|
|
|
|
Given the wording of your sentance, I take it you mean an automation server as an EXE.
Before starting down that long and winding road, be sure to first read about proper exposition of .NET components to COM by reading Exposing .NET Framework Components to COM[^], Marshaling Data with COM Interop[^], and Nick's Exposing .NET Components to COM[^], which covers a few caveats that the SDK docs didn't mention originally - basically about following COM guidelines:- Always attributes classes and interfaces with static GUIDs using the
GuidAttribute - Never change CLSIDs or IIDs for a particular version of an interface
- Never change the definition of a published interfaces; derive a new version from the old and implement that interface as the first interface on the class
- Et cetera...
To create an automation server, however, takes a lot more work. If you want only a single-instance automation server, there's a lot to do, including interop'ing moniker APIs and interfaces, as well as making use of the ROT (Running Object Table) to register your single instance (the moniker is to respond to access requests to the ROT item that represents your application). If you've done this natively, you've got a good start. Now you just need to P/Invoke the native APIs necessary and declare the managed version of interfaces (don't forget their IIDs for their GuidAttribute, as well as the ComImportAttribute that allows the CLR to marshal from COM to .NET and back again). Depending on the derivation of the interfaces, methods have to be declared in order and with the right DispIdAttribute values.
If you want the easy way, then instead of registering into the InProcServer32 registry key, you need to register into the LocalServer32 key. You can do this and still support registration using the regasm.exe tool but attributing a couple of static methods with the ComRegisterFunctionAttribute and ComUnregisterFunctionAttribute. Use the Microsoft.Win32.Registry and RegistryKey classes defined in the .NET BCL (may not - and probably not - available in other CLI implementations' class libraries) to get the CLSID for your attributed class (or hard-code them, since CLSIDs should never change anyway) and register the path to your executable (not to the mscoree.dll shim like COM servers of the DLL variety do).
You should also support the /automation command-line argument in your Main entry point and enable any automation facilities if necessary. At least eat the switch and don't report an error (and/or quit).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Heath,
Thanks,it is very helpful! Besides automation server, are there other ways to have the .net application (exe) to be called by other applications? What do I need to do in order to add the .net exe as a reference in other .net application? Does the exe has to support automation server (with .tlb file) to be included in the reference? Otherwise, I could create a dll in C# that calls the .net exe and have all other applications to call through the dll. Basically, I use the dll as the bridge between the .net exe and other external applications. Is there any sample code on automation server in C# or VB.net? Thanks again.
|
|
|
|
|
VS.NET can't reference EXE assemblies, but you can if you use the command-line compiler (VS.NET is trying to avoid circular references).
You really need to define "to be called by other applications". That's easy. Just invoke the executable. You can use CreateProcess or CreateProcessEx in native code, you can use WshShell.Exec in Windows Script (VBScript, JScript, WSH, WSC, etc.), exec in Perl, etc. All that without automation. You only need to support automation when you want to automate with that application, but there's still other ways to do that: anonymous pipes, named pipes, DDE (archaic, but still supported), and much more.
And how you use "call" is ambiquous. So what if you create a DLL in C#? Do you simply use Process.Start to run it? How then will you interact with it? You could use .NET Remoting (preferred between managed applications) but then you need to develop a protocol for other apps to tell your DLL assembly what to do. Too much complexity.
That wouldn't easily work anyway. Native applications can't simply load your managed DLL into memory. You need to expose that to COM and then COM clients load a shim (mscoree.dll, or a custom shim like Office 2003 apps use) whichs hosts the AppDomain and marshals calls to your .NET components.
Please be clear on your requirements. If all you need to do is start the application than just use one of the methods I mentioned above. No complexity is necessary.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Not just starting the application, I want other applications to call all functions exposed by the application, just like automation server in MFC. Like Excel, the external application can launch Excel, populate data, and perform any tasks that Excel exposed. I wonder why .net does not have an option or tool to support Automation Server as MFC does. Has the automation server (or out-of-process COM server) been replaced by the .net remoting? In another word, can the .net remoting accomplish most of the tasks that the automation server can? From Nick's code, it seems pretty easy to use a .net DLL in MFC. What do I need to do to use a .net Exe as an out-of-process COM server? Thanks again for your response.
|
|
|
|
|
MFC is still native, just native class wrappers for native Win32 APIs. All the COM interfaces necessary are already declared in other headers.
.NET, on the other hand, uses a completely different runtime that works with COM. Some native COM interfaces are re-declared in .NET, but only what is necessary. Anything else is left up to you.
So, it's not that MFC defined all the necessary interfaces - it didn't - but that MFC was native and the COM headers, libs, etc. were native so they went hand in hand.
You really should read about OLE and COM automation before starting such a project. There's a lot of fundamental concepts you need to understand, and COM is a very difficult things to understand (especially the automation interfaces that you would need to use).
Nick's article is not about using a .NET DLL in MFC. That's not even possible unless you're hosting your own AppDomain (this is documented in the .NET Framework SDK as well, under Hosting the Common Language Runtime[^].It's about exposing an assembly as a COM server that MFC can use like any COM server (no matter in what language it was written). As I mentioned before, in this case the default shim registered by regasm.exe - mscoree.dll - is actually loaded into process memory and it hosts the CLR and marshals calls to the .NET assembly (at this point, in what language the assembly was written is moot - all managed languages targeting the CLR compile to IL - that's the point of the Common Language Infrastructure (CLI) on what the .NET Framework (Microsoft's brand) is based).
Read through the documentation at http://msdn.microsoft.com/library/en-us/automat/htm/autoportal_7l45.asp[^] for a better understand of OLE and COM automation.
As far as .NET Remoting goes, you need to weigh your options. So you want to host a managed COM control in MFC that marshals calls across application boundaries to another application? You do realize what's involved, don't you?
First you're marshaling from unmanaged to managed code (and later, back again). Performance hit. Then you're marshaling serializable data (and you have to declare it using the SerializableAttribute and, optionally, implementing the ISerializable interface or using an ISerializationSurrogate implementation with a custom SerializationBinder across TCP ports (the fastest without defining your own custom remoting channels, until .NET 2.0 comes out with an IcpChannel implementation for IPC through named pipes). Then all that repeats in reverse to marshal data back.
And .NET Remoting is a difficult topic, too. Read Accessing Objects in other Application Domains[^] in the .NET Framework SDK for more information.
There's no easy way, and I'm not trying to discourage you, but you really need to read about your options.
The other way is to P/Invoke the necessary native APIs in your managed code and use named pipes to implement a client/server application, which is pretty straight forward.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thanks for the info. I think I find the solution. I've just created a simple .Net Remoting server(which is kind of new to me) and a .Net client. It seems to work nicely as expected. I then created another simple MFC application using managed extensions to simply delegate all calls to the .Net Remoting server. All the non-managed applications can call via the MFC application. I run through a quick test and it seems to work great. I have not yet to test using Process.Start to launch the server if the server is not running, but it should work. One caveat, if I want to use any COM dlls in the .Net Remoting server, the COM dlls must be dual interfaced automation objects (inherit from IDispatch not IUnknown), or I'll get a "QueryInterface failed" error, which seems make sense. I appreciate any suggestions or comments you may have. Thanks again for your help.
|
|
|
|
|
QueryInterface is a method of IUnknown - not IDispatch - so I don't see what could be the problem. More information may be helpful.
For example - have you created an RCW (runtime callable wrapper) or are you trying to create an automation object? Automation objects - i.e., objects that are late-bound - require either dual or IDispatch inheritence in order to invoke methods at runtime.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Sorry, I replied to myself. Please see my last response. Thanks.
|
|
|
|
|
As a test, I had two COM objects: one is inherit from IDispatch and the other is from IUnKnown. The .Net Remoting server can call any functions exposed by these two objects without any error. When a .Net client call the server to access any functions exposed by the IUnknown COM object, it gives "QueryInterface failed" error, but OK for the IDispatch COM object. I am not sure why it needs to call QueryInterface.
|
|
|
|
|
Jason Ruan wrote:
I am not sure why it needs to call QueryInterface.
All methods exposed by IUnknown - which every interface inherits from - is essential to COM. QueryInterface (or just "QI" for us COM-heads, like you QI for an interface) is how you get a reference to an object based on an interface it exposes, or you get E_NOTIMPLEMENTED if it doesn't support that interface. When an interface is attributed with the ComImportAttribute, the CLR will QI for that interface using the compiler-generated GUID or the GUID in the GuidAttribute for that interface when you cast an object to that interface.
Do the clients make calls directly on the COM object through the remoting proxy, or does the remoting object proxy calls to the COM object? If the clients make calls directly on the COM object through the remoting proxy then the client need a reference to the interface, either defined in the client assemblies or exposed in a shared assembly (unlike managed interfaces, you can define interface with the ComImportAttribute how every many times you want, so long as you use it only to communicate with the COM object, not passing the interface itself since the Type must be the same).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Is there a reason for the .NET Framework installation (versions 1.1 or 2.0) to ask for the machine to restart after the installation?
I want to distribute an application (smart client) and I don't know if the customer machine runs the .NET Framework. So I want the customer to run a URL. This will check if the machine has the .NET Framework. If it has then only the application will be installed. If not then the .NET Framework will be installed first and then the application.
I know that there is an Updater application block and in .NET 2.0 the click once support this feature. The "how to install?" is not the point.
The thing that bothers me is the fact that the user will have to restart his/her machine after the .NET Framework installation. This overhead is intolerable. I just want it to be opaque for the customer that he/she uses a smart client.
From my experince the .NET Framework installation never asked for restart (1.1 and 2.0), but a friend told me that he was asked to do it.
Does anyone know what are the cases which the .NET Framework asks for restart?
|
|
|
|
|
The .NET Framework does not require a restart - the service pack does (trust me - I help create them). If you go to MSDN and download just the RTMs a reboot will not be necessary (unless, of course, you installed a service pack and haven't reboot yet). When you install the service pack a reboot is required because files are in use. I can't go into details.
The best way is to write your own bootstrapper that eats the reboot code (return code 3010) and proceeds to install your application. You might warn the user that they should reboot later but it most likely won't be necessary depending on what native libraries or assemblies you use in your application.
Writing your own bootstrapper isn't hard. See Using the Setup.exe Bootstrapper Sample with an Application (.NET Framework Developer's Guide)[^] for more information and an example.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Ami Bar wrote:
Does anyone know what are the cases which the .NET Framework asks for restart?
Most modern installers need to restart a machine when some file they need to replace/upgrade is in use.
Yes, even I am blogging now!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
