|
|
Could someone point me in the direction of an article perhaps on how to write DLL's in C# and call them from C++ or Delphi or something other than a .NET language?
I'm hoping this is even possible?
Cheers
|
|
|
|
|
Dewald wrote: I'm hoping this is even possible?
Exposing the .NET assembly as either COM objects or Web Services would do that. Alternatively you can use C++/CLI to reference the C# managed assembly (DLL), wrap the .NET object API and expose a Native C++ or C API that non .NET languages can call. Based on the small amount of information you provided I would guess COM might be a good solution for you.
|
|
|
|
|
|
I have been programming in C# for years now, but I have never gotten a straight answer on this:
we always declare "using System.Whatever" at the top of a .cs file to make life easier when we program, but is there a cost associated with having many of them declared, especially (or even) if they arent used, or are they treated much the same as comments and they get stripped out during the compile if they arent used?
It's been bugging me for years.
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
Hello,
Look at this thread[^] and specially at "Guffa's" post!
All the best,
Martin
|
|
|
|
|
Awesome, thank you 
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
From what I understand is that the using statements work the same as in C++ in the since you don't have to add the namespace to each command you are trying to use/call, but they have the added benefit of calling the garbage collector to look for those associated objects in your code. Makes is so you don't have to manually call dispose to it for the mem to be cleaned up during exit.
I guess there might be a *small* downfall to them but, I doubt it is worth messing with and isn't much faster than removing one IO write....
more info here: http://msdn2.microsoft.com/en-us/library/zhdeatwt(VS.80).aspx[^]
|
|
|
|
|
I think you're mixing the concepts. There are "using directives", which the OP is mistakenly calling "statements", that appear at the top of the code file and tell the compiler that you are "using" types out of the specified namespace.
The "using statements" are a type of syntax shorthand for wrapping an IDisposable type in a try/finally block. They are completely independent and separate from one another. The only commonality is that they, unfortunately, share the same keyword.
|
|
|
|
|
Correct, the C# Specification (section 9.3) calls them directives. I think much of the confusion is that they don't have a leading # like "normal" directives.
And, perhaps, many beginners don't learn the actual using statement, so they don't know the difference.
Plus, a lot of books confuse the issue; looking in three I have here:
"Professional C#" (Wrox), page 40, says, "using statement"
"Developing Web Applications" (Microsoft), page 93, says "using statement"
"C# for Dummies", page 331, says, "using command"
|
|
|
|
|
Yes...there is a lot of confusion around this. It would have been better to prefix them with the "#" or use a different keyword (like include or import). Unfortunately, I don't see this changing since it would break everything. 
|
|
|
|
|
It makes life easier for you. Consider it shorthand. It doesnt affect your compiled code at all. (You'll be surprised how many different ways you can do things before it changes the IL).
|
|
|
|
|
No, they don't adversely affect the program; they simply save the programmer many many many keystrokes. And my opinion of them is pretty well documented in that other thread so I won't repeat myself yet again other than to say, "I don't use them".
On the other hand, most practitioners don't advance beyond the very simplest use of the using directive.
For instance, one could write
using System.Collections.Generic ;
...
Dictionary<string,object> mystuff = new Dictionary<string,object>() ;
Dictionary<string,object> yourstuff = new Dictionary<string,object>() ;
Dictionary<string,object> hisstuff = new Dictionary<string,object>() ;
but one could also write
using LookupTable=System.Collections.Generic.Dictionary<string,object> ;
...
LookupTable mystuff = new LookupTable() ;
LookupTable yourstuff = new LookupTable() ;
LookupTable hisstuff = new LookupTable() ;
which has the benefits of saving even more keystrokes, makes the program easier to maintain (the definition of LookupTable only needs to be changed in one place), and may just be better OOP.
(And less time replacing <s with <s when posting on CP!)
Another use for the using directive is this
using DatabaseConnection=System.Data.SqlClient.SqlConnection ;
using DatabaseCommand =System.Data.SqlClient.SqlCommand ;
using DatabaseReader =System.Data.SqlClient.SqlDataReader ;
using DatabaseParameter =System.Data.SqlClient.SqlParameter ;
using DatabaseAdapter =System.Data.SqlClient.SqlDataAdapter ;
...
then, if the underlying database technology changes, only the using directives need be modified; again, simplifying maintenance.
Taking that to the next level, we can make the selection of the actual database classes a compile-time issue
# if SqlClient
using DatabaseConnection=System.Data.SqlClient.SqlConnection ;
using DatabaseCommand =System.Data.SqlClient.SqlCommand ;
using DatabaseReader =System.Data.SqlClient.SqlDataReader ;
using DatabaseParameter =System.Data.SqlClient.SqlParameter ;
using DatabaseAdapter =System.Data.SqlClient.SqlDataAdapter ;
...
# endif
# if OleDb
...
# endif
# if MySql
...
# endif
...
The problem with this technique is that one must ensure that one and only one of the database systems is defined -- this is an unfortunate side-effect of Microsoft gutting the C preprocessor for use with C#.
Using the standard C preprocessor, one can write
# define SqlClient 1
# define OleDb 2
# define MySql 3
# define UseDatabase 1
# if (UseDatabase==SqlClient)
using DatabaseConnection=System.Data.SqlClient.SqlConnection ;
using DatabaseCommand =System.Data.SqlClient.SqlCommand ;
using DatabaseReader =System.Data.SqlClient.SqlDataReader ;
using DatabaseParameter =System.Data.SqlClient.SqlParameter ;
using DatabaseAdapter =System.Data.SqlClient.SqlDataAdapter ;
...
# endif
# if (UseDatabase==OleDb)
...
# endif
# if (UseDatabase==MySql)
...
# endif
|
|
|
|
|
Good explanation on the different ways to use the using directive. It is unfortunate that we don't have a bit more in the preprocessor to at least allow the #define statments.
|
|
|
|
|
Oh, and I left out the use of the using directive to write
using WinForms=System.Windows.Forms ;
using WebForms=System.Web.UI.WebControls ;
...
WinForms.Button b1 = new WinForms.Button() ;
WebForms.Button b2 = new WebForms.Button() ;
(But then, only I would be crazy enough to do that.) 
|
|
|
|
|
Nice, i like this one...
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
Vodstok wrote: at the top of a .cs file
Which is another misconception... Did you know... that you can put a using directive inside a namespace? I didn't until the subject came in that other thread.
|
|
|
|
|
Hi,
I'm using VS2005 and I have a settings file in my project whose items are user-scoped. Is there way to save them to a different file instead of the auto-generated config file which is under the C:/Documents and Settings/blah blah blah....
|
|
|
|
|
use System.Xml or System.IO to write and read your own custom file...
|
|
|
|
|
|
Hi,
I need some information about calling events of web application through windows application by httpwebrequest nd response
Actually I want to execute all events of web application through request…., but I only succeed for server side control's event and not for client side control like anchor element like that…….
I am implementing all these from windows application…..., If u have any information then please reply….……..
Dipti Jadhav
|
|
|
|
|
What is the diff between Sender property of MailMessage and From property of MailMessage.
What is the difference between ReplyTO and ReturnPath
they have same meaning in usage. dont they ?
Now my client wants to use these things with unique cases
when a reciever hits reply it should use ReplyTo address (which it does)
When a mail is getting bounced or if there is some error then it should use ReturnPath
Man! Now it is coming down to client sending me RFCs and still i'm not able to figure out the difference and how i can utilize all these properties.
Regards
|
|
|
|
|
Have you looked at the RFC 2822[^] for email messages?
From §3.6.2 Originator fields
The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the mailbox(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message.
From RFC 2821[^], §6.1 If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line).
So...to directly your questions:
logicaldna wrote: What is the diff between Sender property of MailMessage and From property of MailMessage.
What is the difference between ReplyTO and ReturnPath
they have same meaning in usage. dont they ?
Now my client wants to use these things with unique cases
The "From:" field specifies the author(s) of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message.
The "Reply-To:" field (if it is present), indicates the mailbox(es) to which the author of the message suggests that replies be sent.
The "Return-Path" field indicates the mailbox that a delivery failure notification should be sent to.
You need to get specific cases, including all of the edge cases clearly documented from your client.
It sounds like you are trying to write an SMTP compliant email system. I'd recommend using one of the commercially available versions instead of trying to do it yourself as there are a ton of rules that need to be followed and some of them are fairly non-trivial.
|
|
|
|
|
Scott Dorman wrote: if a secretary were to send a message for
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field.
isn't that a spoofing ?
When a mail is generated and sent by system, i need to have a User Role ID (Persons ID ) at FROM and a Admin ID at Sender,
I can do this using SMTPClient but i can not mention Return path using the same
Scott Dorman wrote: It sounds like you are trying to write an SMTP compliant email system
No ways, i can live with whatever .net provides
Thanks for the details !
|
|
|
|
|
In a way it's spoofing. Essentially what is happening in this case is that the secretary is sending the email "on behalf of" the boss. According to the RFC rules, since the secretary actually sent the message that email address appears as the "Sender", but the bosses email address appears as the "From" since that is who actually authored the email.
There is a very fine line between true spoofing and following the rules of the RFC. In most cases spoofing is impersonating both the author and the sender.
If you are just uisng the email messaging capabilities of .NET to send the message, a lot of these rules should already be established for you. The Return-Path field is actually more a function of the actual SMTP system rather than the message, so it may already be present when the email is delivered. There are also rules for what happens if it isn't present at all, so it may not be an issue.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
