msgraph-sdk-dotnet
msgraph-sdk-dotnet copied to clipboard
Add SDK support for downloading MIME content stream for Message objects
Recently, the Graph API implemented an endpoint that can get the MIME content of a message.
The Graph SDK exposes no interface to access this endpoint in a fluent manner. The only way to use the $value
endpoint is to make a direct request using the IHttpProvider
associated with the GraphServiceClient
. An interface to get the stream should be added to IMessageRequestBuilder
and implemented similarly to other content request builders like DriveItemContentRequestBuilder
.
There are a few ways this could be done:
- Update the
$metadata
endpoint of the Graph service to add theHasStream
property to the<EntityType BaseType="microsoft.graph.outlookItem" Name="message"/>
type, and then rerun Typewriter to generate the new files. This would work, however it will generatePutAsync
implementations for the stream, which the endpoint doesn't support. - Add a
/content
endpoint to the Message item which acts as an alias for$value
, then update the metadata to get content. AB#6266
@michael-celani-relativity Thank you for the detailed instructions on how we can add this feature! We'll hopefully address this soon.
https://stackoverflow.com/questions/60992118/how-to-use-value-using-microsoft-graph-library-in-c-sharp
Current workaround:
var attachmentRequestBuilder = client.Me.Messages[msgId].Attachments[attId];
var fileRequestBuilder = new FileAttachmentRequestBuilder(attachmentRequestBuilder.RequestUrl, client);
Console.WriteLine($"Request URL: {fileRequestBuilder.Content.Request().RequestUrl}");
var stream = await fileRequestBuilder.Content.Request().GetAsync();
using(var reader = new StreamReader(stream))
{
Console.WriteLine("Attachment contents:");
while (!reader.EndOfStream)
{
var line = reader.ReadLine();
Console.WriteLine(line);
}
Add AttachmentRequest, something like:
public System.Threading.Tasks.Task<string> GetAsMIMEAsync(CancellationToken cancellationToken)
{
this.ContentType = "text/plain";
this.Method = "GET";
this.AppendSegmentToRequestUrl("$value");
return await this.SendAsync<string>(null, cancellationToken).ConfigureAwait(false);
}
cc: @jasonjoh
I ran into this short cumming as well, but oddly enough the docs say it's possible, yet the code doesn't work https://docs.microsoft.com/en-us/graph/api/message-get?view=graph-rest-1.0&tabs=csharp#tabpanel_CeZOj-G++Q-3_csharp
I ended up filing an issue on the docs to fix it, but I was impatient and ended up creating the supporting code to get it to work without waiting for an official fix. microsoftgraph/microsoft-graph-docs-contrib#4804
have we got any official fix yet?
@MIchaelMainer is this still needed?
I would say so. Though It's worth pointing out that the Graph API exposes this functionality to get the MIME content, the .NET SDK's documentation even claims that it also supports calling this endpoint of the API. But in actuality, the SDK's implementation doesn't exist. At a bare minimum, the SDK should be updated so it functions the way the documentation claims it does, or the documentation should be updated to explicitly indicate it does not provide support for the method and that it's up to the user to implement it themselves.
Related. https://github.com/microsoftgraph/msgraph-sdk-java/pull/520. Still needed
I would say it still needed. Getting MIME content should be one of the basic functions of SDK.
Just wanted to chime in, and mention that getting the MIME type for a message works as expected with the 5.0 version of the SDK client (C#). Don't know if this will ever get patched for 4.x given how old this ticket is, and there being a workaround.
Example of how to do it with 5.0
var graphClient = new GraphClient(/*auth details excluded for brevity*/);
var stream = await graphClient.Users["[email protected]"].Messages[/*MessageId, ommited here for brevity*/].Content.GetAsync();
//If you want this as a string
var mimeString = new StreamReader(stream).ReadToEnd();
Thanks for confirming this @nickalbrecht
We'll close this as this was fixed in v5 and a workaround is available for v4.
I found an old comment of mine on my mentioned Docs ticket that says it appeared to be fixed in 4.x, I think it was broken in earlier versions. But I guess this ticket never got confirmed if it was done or not. Either way, definitely safe to close :-P