|
Is IIS installed and running?
Mike Lasseter
|
|
|
|
|
Bah, I've been working on this forever now and I can't seem to find why this error happens.
Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'Ingramtest.Order(1359c91a-86bf-d041-3a7a-ef48ebb10fa7)'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: 198894a5-41a3-407a-bc2f-2e492cc9ed03
Shape name: Send_7
ShapeId: efb1d8a7-4fa2-4f3d-b135-7119a999de7d
Exception thrown from: segment 1, progress 36
Inner exception: Exception occurred when persisting state to the database.
Exception type: PersistenceException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void Commit()
The following is a stack trace that identifies the location where the exception occured
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXXlangStore.Commit()
at Microsoft.XLANGs.Core.Service.Persist(Boolean dehydrate, Context ctx, Boolean idleRequired, Boolean finalPersist, Boolean bypassCommit, Boolean terminate)
at Microsoft.XLANGs.Core.ServiceContext.PendingCommit(Boolean ignore, XMessage msg)
at Microsoft.XLANGs.Core.ExceptionHandlingContext.PendingCommit(Boolean ignoreCommit, XMessage msg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.SendMessage(Int32 iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlation[] followCorrelations, SubscriptionWrapper& subscriptionWrapper, Context cxt, Segment seg, ActivityFlags flags)
at Microsoft.XLANGs.Core.PortBase.SendMessage(Int32 iOperation, XLANGMessage msg, Correlation[] initCorrelations, Correlation[] followCorrelations, SubscriptionWrapper& subscriptionWrapper, Context cxt, Segment seg)
at Ingramtest.Order.segment1(StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
Additional error information:
A batch item failed persistence Item-ID 2c1195f7-fb56-4043-86b6-4aeeae7f8dd5 OperationType MAIO_CommitBatch Status -1061151960 ErrorInfo An error occurred when accessing the part data or one of its fragments. The part data or fragment may not exist in the database. .
Exception type: PersistenceItemException
Additional error information:
Failed to publish (send) a message in the batch. This is usually because there is no one expecting to receive this message. The error was An error occurred when accessing the part data or one of its fragments. The part data or fragment may not exist in the database. with status -1061151960.
Exception type: PublishMessageException
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
WM.
What about weapons of mass-construction?
|
|
|
|
|
I found the problem, at least I think I did.
The problem ocurred when I copied a message so that I had two messages of the same type. Removing the duplicate solved the problem.
But now there's a different problem, but I will contact MS about that, since there's a hotfix for it 
WM.
What about weapons of mass-construction?
|
|
|
|
|
what is GAC(Global Assembly Cache)
Does any one know what is meant by digitally signing an assembly.
I any of you can provide useful link, i will be thankful to that person.
Warm Regards,
Mushq
|
|
|
|
|
The Global Assembly Cache is a location which the .NET Framework looks in for shared assemblies (used by more than one program). It looks here first for assemblies which have a strong name, which is a name that includes the version number, culture, and a public key token which identifies the publisher of that assembly. If not found in the GAC it will then fall back to the application directory and directories under it in the same way as for non-signed assemblies.
To ensure that the assembly has not been tampered with, it is digitally signed. This means that public-key cryptography has been used to attach a digital signature to the assembly. A hash (a fixed-size value generated by a one-way function which is highly likely to be unique to a particular input file) is generated, then that hash is encrypted with the publisher's private key to form the signature. On the end-user's system, the publisher's corresponding public key can then be used to decrypt the signature and compare it with re-computing the hash value. If they match, the assembly has not been altered and can potentially be assigned a level of trust as appropriate.
The public key token is a hash of the public key data, used because it is significantly shorter than the public key itself. If I recall correctly, the public key itself is actually attached to the binary since it is required for checking the signature.
Note that although this is a public/private key pair is used, this does not mean the key used has to be part of a public key infrastructure. You don't need to buy one from a Certification Authority, as you do with SSL or Authenticode code-signing certificates - you simply generate a key pair using the sn.exe utility.
|
|
|
|
|
I am using .net CF with PPC 2003 and SQLCE 2.0. I am having trouble getting a simple pull of a table to the emulator. I am getting an HRESULT error 28037. I am not sure what to do. Here is a clip of the code. Does anyone have an idea?
thanks,
Saurabh Gupta
Software Engineer
|
|
|
|
|
Hi All,
I want to read more about how framework 2.0 work - i looked in Microsoft site but i don't find anything that will explain to me what to do to work in better performance and how all work in the background.
Thanks for any help.
|
|
|
|
|
|
There is no site that can explain ?
|
|
|
|
|
There will be articles but they wiil be scattered around.
Kevin
|
|
|
|
|
try
{
...
XmlReader rdr = XmlReader.Create(input_XML_file, settings);
}
catch (Exception ex)
{
...
}
if there's a problem reading/parsing the file, and the code ends up in the catch, the file is left open (can't rename, delete, move, etc). shutting down VS and all of its little spawned web servers doesn't help.
by changing the code to open the file as a StreamReader, then using that Stream as the source to XmlReader.Create, i can explicitly Close the Stream in the catch, and the file is not left locked.
|
|
|
|
|
No, it's not a bug. You left it open, so it works exactly as it should.
The XmlReader class implements IDisposable, so you can use that to make sure that it's closed:
using (XmlReader rdr = XmlReader.Create(input_XML_file, settings)) {
...
}
---
b { font-weight: normal; }
|
|
|
|
|
i didn't leave anything "open", because i didn't open anything. i gave XmlReader a filename and XmlReader opened the file. XmlReader then left the file open after it threw an exception. and XmlReader left the file open even after the program exited - not me.
|
|
|
|
|
Chris Losinger wrote: i didn't leave anything "open", because i didn't open anything. i gave XmlReader a filename and XmlReader opened the file. XmlReader then left the file open after it threw an exception. and XmlReader left the file open even after the program exited - not me.
If you think like that, then you never open anything ever. You just give a filename to the File.Open method and it opens the file. You just give a connection string to the SqlConnection object, and it opens the database connection.
Just because you don't call the interrupt that opens the file yourself, doesn't free you from the responsibility to make sure that it's closed properly.
---
b { font-weight: normal; }
|
|
|
|
|
that's just silly. surely you can see the difference between a function called "File.Open" and one called "XmlReader.Create".
in one case the caller expects and gets an open file, because that's the reason for calling the function. in the other, the caller doesn't get an open File object, has no access to any open File object, and isn't expecting one - the opened file is an undocumented side-effect.
Guffa wrote: Just because you don't call the interrupt that opens the file yourself, doesn't free you from the responsibility to make sure that it's closed properly
if it's the caller's responsibility that the XmlReader user should close the file, then why does XmlReader close the file by itself in some situations but not others; and why does the MSDN fail to mention anything about this behavior, or this "responsibility" ?
at best, this function is inconsistent in behavior and poorly-documented.
|
|
|
|
|
Chris Losinger wrote: then why does XmlReader close the file by itself in some situations but not others
Because it has a finalizer which closes the file for you, but this is not deterministic - you cannot predict when this will occur.
Anything which implements IDisposable should be Disposed by the programmer when the object has been finished with. That's the rule I follow. You can use a using block to automatically call Dispose when execution leaves the block - this includes exits due to exceptions as well as normal program execution.
Finalizers run on a single separate finalizer thread, which processes a queue of finalizable objects. An object with a finalizer gets pushed onto the end of the queue when the garbage collector runs, unless GC.SuppressFinalize has been called on the object (this is usually done by the implementation of Dispose). The finalizer thread runs the finalizers asynchronously with respect to the rest of the program. Only when the finalizer has run can the memory that the object was occupying be freed. Best practice is to avoid having objects end up in the finalizer, to reduce the memory load and to avoid synchronization problems with finalizers.
|
|
|
|
|
I don't know if the object representing the file has a finalizer, but if it does, then I don't think XmlReader would have one. As you might be knowing, the order in which finalizers are called is undefined, so it's possible the file object gets finalized before the XmlReader instance does.
|
|
|
|
|
OK, XmlReader itself does not have a finalizer. The FileStream which is managed by the XmlReader does. The rest of my comments still apply - you have to dispose anything that's disposable.
|
|
|
|
|
Mike Dimmick wrote: The rest of my comments still apply - you have to dispose anything that's disposable.
No question about that. I totally agree.
|
|
|
|
|
Chris Losinger wrote: that's just silly. surely you can see the difference between a function called "File.Open" and one called "XmlReader.Create".
If course there are differences, but that is not really relevant. You seem to fail to see the similarities.
Chris Losinger wrote: in one case the caller expects and gets an open file, because that's the reason for calling the function. in the other, the caller doesn't get an open File object, has no access to any open File object, and isn't expecting one - the opened file is an undocumented side-effect.
You never get direct access to an open file through the framework. You access files through streams, readers and writers.
Chris Losinger wrote: if it's the caller's responsibility that the XmlReader user should close the file, then why does XmlReader close the file by itself in some situations but not others; and why does the MSDN fail to mention anything about this behavior, or this "responsibility" ?
at best, this function is inconsistent in behavior and poorly-documented.
The reader closes the file if it knows that you can't use it any more. If you don't tell it anything and just leave it hanging, it can't close the file.
I don't really think that the documentation is poor, but it is not always easy to read. Some things are not spelled out as clearly as you would like, and some things are only mentioned once and not exactly where you expect it.
---
b { font-weight: normal; }
|
|
|
|
|
Guffa wrote: You seem to fail to see the similarities.
because the similarities are not documented.
Guffa wrote: You never get direct access to an open file through the framework. You access files through streams, readers and writers.
that completely misses the point
Guffa wrote: If you don't tell it anything and just leave it hanging, it can't close the file.
it closes the file when it succeeds, but leaves the file open when it fails. if it knows how to do it in one case, it should know how to do it in the other.
what is gained by having code do something as potentially problematic as leaving a file open in one case, but not another, and not telling callers that this happens ?
would you ever write code that behaved that way? i wouldn't.
Guffa wrote: Some things are not spelled out as clearly as you would like, and some things are only mentioned once and not exactly where you expect it.
that's pretty much the definition of "poor documentation". the only thing worse is no documentation at all.
|
|
|
|
|
Chris Losinger wrote: because the similarities are not documented.
Why do you complain about it being inconsistent then? 
Chris Losinger wrote: that completely misses the point
Does it? If you use an XmlReader to open a file, don't you expect the file to be opened? Is it just that the method doesn't have "File" and "Open" in the name?
Chris Losinger wrote: it closes the file when it succeeds, but leaves the file open when it fails. if it knows how to do it in one case, it should know how to do it in the other.
Just because you do something that causes an exception, that doesn't automatically mean that you don't want to use the reader any more.
Chris Losinger wrote: that's pretty much the definition of "poor documentation".
Then you really haven't seen any poor documentation...
---
b { font-weight: normal; }
|
|
|
|
|
Guffa wrote: If you use an XmlReader to open a file, don't you expect the file to be opened?
of course. but i also expect it to be closed.
if you open a file, and you don't expect (or even allow) the caller to do anything with the file you've opened, then there is absolutely no reason for you to keep the file open - especially after you've gone out of scope.
|
|
|
|
|
Chris Losinger wrote:
of course. but i also expect it to be closed.
Yes, if you close the reader, it will close the file.
Chris Losinger wrote: if you open a file, and you don't expect (or even allow) the caller to do anything with the file you've opened, then there is absolutely no reason for you to keep the file open
How do you expect the reader to read from the file if it's not kept open?
Chris Losinger wrote: - especially after you've gone out of scope.
Yes, there is no reason to keep the file open after that, but the problem is that it has no relevance at all from the object's point of view. The object has no way of telling that the reference to it has gone out of scope.
---
b { font-weight: normal; }
|
|
|
|
|
Guffa wrote: Yes, if you close the reader, it will close the file.
the reader closes the file just fine if everything works. it clearly knows how to close the file that it opened without any assistance from me.
Guffa wrote: How do you expect the reader to read from the file if it's not kept open?
i don't expect it to keep reading at all - it threw an exception. if it could keep reading, it should've just kept reading.
i've had enough. ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
