OK, I have downloaded the source code (PDFsharp-MigraDocFoundation-1_50-beta5) from SourceForge and made some changes to get it to work in Medium trust.
First I added the [assembly: AllowPartiallyTrustedCallers] attribute to AssemblyInfo.cs in all assemblies (other than the *-gdi and *-wpf assemblies, which I have not used). I presume that the attribute is needed because those assemblies target the .NET Framework 2.0; it might not be needed if they were targeting a more recent version of the Framework.
Then I re-built the assemblies, referenced the re-built assemblies in my application, and ran the application in Medium trust. The original "That assembly does not allow partially trusted callers" was gone but I got a problem when the application attempted to add an image to the PDF document:
var image = section.Headers.Primary.AddImage(imageFilePath);
This caused the following exception:
System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.CodeAccessPermission.Demand()
at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
at System.IO.Directory.InternalGetCurrentDirectory(Boolean checkHost)
at MigraDoc.DocumentObjectModel.Shapes.Image.GetFilePath(String workingDir)
at MigraDoc.Rendering.ImageRenderer.Format(Area area, FormatInfo previousFormatInfo)
(...)
The GetFilePath method of the Image class makes a call to Directory.GetCurrentDirectory(), which is not supported in Medium trust.
As my application passes the full, absolute path to the image, I thought that there was no need for the Image.GetFilePath method to try and build the path, so I added the following code to that method (immediately below if (Name.StartsWith("base64:")) return Name;):
if (Path.IsPathRooted(Name))
return Name;
Note that Path.IsPathRooted returns true if the path is an absolute path but may also return true in some other cases (e.g. if the path starts with a '/' character). So this may need to be refined. However, this was good enough for my purposes.
Having done that, I then got into the expected problem with fonts:
System.Security.SecurityException: Request failed.
at PdfSharp.Drawing.XFontSource.ReadFontBytesFromGdi(Font gdiFont)
at PdfSharp.Fonts.PlatformFontResolver.CreateFontSource(String familyName, FontResolvingOptions fontResolvingOptions, Font& font, String typefaceKey)
at PdfSharp.Fonts.PlatformFontResolver.ResolveTypeface(String familyName, FontResolvingOptions fontResolvingOptions, String typefaceKey)
at PdfSharp.Fonts.FontFactory.ResolveTypeface(String familyName, FontResolvingOptions fontResolvingOptions, String typefaceKey)
(...)
So I implemented a custom IFontResolver implementation, as suggested in the FAQ and following the example in
http://developer.th-soft.com/developer/ ... -migradoc/ , to load font data from private font files included as part of the web application.
I was then able to successfully create a PDF document when running in Medium trust, both on my local machine and on the web server of our web hosting provider.
Note however that my application, at this stage, does not do much with PDFsharp/MigraDoc (it just contains code to create one particular PDF document, quite similar to the "Invoice" sample provided as part of the MigraDoc samples in the PDFsharp web site). It is possible that other, more sophisticated applications could encounter other problems in Medium trust).