ASP、Server.CreateObject、MTS和C#对象池--重用问题？

我正在调试一个“偶然”的问题。我们有一个经典的ASP应用程序，需要发送电子邮件。无论出于何种原因，它都使用通过COM公开的C#对象来执行此发送；c#对象是围绕MailMessage和SMTPClient的简单包装器，使用SendAsync进行发送。在ASP端，在发送每封邮件之前，对象是Server.CreateObject（）'d，但邮件消息以紧密循环的方式发送。这将为每条消息生成一个新的COM对象（因此也是一个新的c#对象）。但是，我们看到消息被丢弃，消息被发送到多个收件人，就好像对象被重用一样

在对MTS进行了一些研究之后（从没想过我会再去那里！），我记得/发现Server.CreateObject经过MTS，MTS将汇集COM对象以“帮助”我。我们已经更改了ASP代码，改为创建一个新的ActiveXObject，我认为它没有经过MTS，但我们也遇到了同样的问题

假设.net中的ServicedComponent接口是ObjectControl接口的.net/com+版本，对吗？如果我从ServicedComponent继承，那么对象是否会被设置为允许池=false？我宁愿在ASP中进行更改，但如果不可能，那么我也可以进行c#更改

想法

---

编辑：页面语言也是JScript，而不是“普通”VBScript。

Server.CreateObject和新的ActiveXObject在这种情况下都是相同的

COM+不会池化未明确指示可以池化的对象

我倾向于调查使用.NET组件的原因，为什么不使用CDO.Message？SendAsync的使用尤其令人困惑。如果你只是发送电子邮件，那么SendAsync对你的帮助很小

在这种情况下，我想不出一个避免使用CDO.Message的好理由，但当然，这可能是因为我们忽略了其他因素

大多数“你到底为什么……”问题的答案是：“因为我们继承了这段代码”：-）不幸的是，客户希望我们花大量时间“修复”问题，然后重写部分代码。嘿这是他们的一角硬币。如果.NET对象不从ServicedComponent继承，那么COM+不会将其池化？CanPool的默认实现为false，但如果.net对象不继承，则不存在默认值。我们在一个循环中发送电子邮件，但是每个电子邮件都有自己的COM对象，所以它有自己的SMTPClient，所以异步应该可以。除非COM对象被重用。