Using Atalasoft's free SDK,
http://www.atalasoft.com/free-dotnet-image-sdk
I added reference to the DotImage and DotImage.Lib dlls' to Visual Studio 2010.
My code:-
Atalasoft.Imaging.AtalaImage image = new Atalasoft.Imaging.AtalaImage(fileName);
Atalasoft.Imaging.Codec.TiffEncoder encoder = new Atalasoft.Imaging.Codec.TiffEncoder();
encoder.Compression = Atalasoft.Imaging.Codec.TiffCompression.Group4FaxEncoding;
image.Save(fileName, encoder, null); // destroys the original.
However when I run the code I get an error on the very first line:-
Unable to retrieve security descriptor for this frame.
Can anyone help me out with this?
Update:-
I added a further line of code:-
System.Security.Permissions.FileIOPermission f2 = new System.Security.Permissions.FileIOPermission(System.Security.Permissions.FileIOPermissionAccess.AllAccess, fileName);
Still the same error.
Philo,
Hi, I'm the support engineer you called in to yesterday. I apologize - after you called in, I received a note from our chief software architect asking us to help you out.
If you are still experiencing your issue, please do call back in and/or create a support case on our portal at https://www.atalasoft.com/support/my-portal/cases
A couple of tings that come to mind from your case: make sure you're targeting either x86 or x64 in your project's platform target (DotImage "has bitness") and make sure you're using the appropriate x86 or x64 Atalasoft references. (I strongly suggest our x86 while getting started as x64 has some additional hoops to jump through to get the licensing working.
Atalasoft does ship some AnyCPU dlls but they're for an extremely limited subset of use cases and if you have referenced those and/or are attempting to target your project to AnyCPU, this will cause all sorts of odd behavior.
Also, if you're targeting our .NET framework 4.0, make sure you're targeting the full framework and not "Client Profile" as DotImage has dependencies on components not present in the Client Profile version.
~DigitalSorceress
Did you have the the file with .lic extension in project section on the right side? Make sure about that.
Related
First up, I'm fairly new to .NET and C# and this is a project to learn C# and CEF at the same time.
I have followed a number of tutorials from the net as well as looking into the CefSharp examples to create a WinForms application.
I have installed CefSharp.WinForms 53.0.1 from NuGet, and my project is using Any CPU (CefSharp 51+ has Any CPU support).
To achieve this I largely followed the tutorial from Ourcode (http://ourcodeworld.com/articles/read/173/how-to-use-cefsharp-chromium-embedded-framework-csharp-in-a-winforms-application). I made the changes for Any CPU as suggested and included the basic code to load google.
Everything builds fine, but when the form displays there's no browser shown, just a blank form.
If I set the target to x64 or x86, then the browser displays as expected.
I notice in the Ourcode comments that user Edek Halon has had the same issue, but no solution seems to be provided. Edek, has the same setup as me, so I wonder if this is an issue in 53.0.1? Potentialy Joey De Vries in the comments has the same issue.
The addition of support for Any CPU in CefSharp is covered in this GitHub issue : https://github.com/cefsharp/CefSharp/issues/1714
There is a troubleshooting page for CefSharp (https://github.com/cefsharp/CefSharp/wiki/Trouble-Shooting) and it seems a bit contradictory. Under General Troubleshooting
1) Platform Target You must select either x86 or x64 when using the NuGet packages. If you select AnyCPU the NuGet magic won't work currently.
Does CefSharp need to be built from source for Any CPU to work?
Just if anyone is having difficulties with this, follow the Github Tutorial at the following link : https://github.com/cefsharp/CefSharp/issues/1714
Basically the code should be as follows (Winforms Example):
CefSharpSettings.SubprocessExitIfParentProcessClosed = true;
Cef.EnableHighDPISupport();
CefSettings settings = new CefSettings
{
CachePath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "CefSharp\\Cache"), //By default CefSharp will use an in-memory cache, you need to specify a Cache Folder to persist data
BrowserSubprocessPath = #"x86\CefSharp.BrowserSubprocess.exe"
};
Cef.Initialize(settings, performDependencyCheck: true, browserProcessHandler: null); // Initialize cef with the provided settings
chromeBrowser = new ChromiumWebBrowser("http://ourcodeworld.com"); // Create a browser component
this.Controls.Add(chromeBrowser); // Add it to the form and fill it to the form window.
chromeBrowser.Dock = DockStyle.Fill;
I'd like to use a piece of Windows 10 specific UWP API (specifically, the Windows.Graphics.Printing3D stuff) in an ASP.NET code-behind DLL. Is there any way to do so?
While looking for a .NET-only resolution to this one, I've found a moderately clean way - a Win32/64 C++ DLL that would consume UWP API and present a COM- or P/Invoke-based interface to .NET.
Create a regular Win32 DLL. Build an interface for .NET to consume - exported functions or objects, depends. In my case, a single exported function will do. In the project's C/C++ settings, make the following changes:
Under General, set Consume Windows Runtime Extensions to Yes.
Under General, set Additional #using Directories to: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcpackages;C:\Program Files (x86)\Windows Kits\10\UnionMetadata (assuming Visual Studio 2015)
Under Code Generation, set Enable Minimal Rebuild to No (it's only Yes for Debug, not for Release).
Then instantiate and use UWP components in the DLL in the usual C++/CX manner, like you would in a Store app, via using namespace Windows::... and ref new.
In this approach, you lose bitness agnosticism; an unmanaged DLL can't be "Any CPU". You win some, you lose some. Also, the site will not run without the Visual C++ redistributable package on the system. On the other hand, it may run faster than a .NET app; less managed/native boundary crossings.
Inspiration: "Using C++/CX in Desktop apps" by Pavel Y.
Open the project file as XML, and paste the following line under the first <PropertyGroup>:
<TargetPlatformVersion>10.0</TargetPlatformVersion>
Once you do that, the Add reference dialog will include UWP libraries, and the file type options in the "Browse..." dialog there will include .winmd.
Load the project, do Add reference/Browse, locate C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd, add that.
There are some helpful extension methods in the managed assembly System.Runtime.WindowsRuntime (e. g. IBuffer.AsStream()), but for some reason, it's not listed under Assemblies. To reference it, you'd need to edit the project file directly, and under the first <ItemGroup>, add the following:
<Reference Include="System.Runtime.WindowsRuntime" />
Unlike the guide states, you don't need to change the compilation target to x86 or x64; leave AnyCPU be.
For desktop .NET applications, this is sufficient. For ASP.NET, however, there's a catch. The way the ASP.NET runtime sets up its AppDomains not compatible with UWP. It's probably a bug deep down, but I've reported it, and a Microsoft rep said the whole thing was not a supported scenario to begin with.
Anyway, you have to change the LoaderOptimization policy of the AppDomain to SingleDomain. The quickest way to do so is via abusing a private method of AppDomain:
AppDomain ad = AppDomain.CurrentDomain;
MethodInfo mi = ad.GetType().GetMethod("SetupLoaderOptimization", BindingFlags.Instance | BindingFlags.NonPublic);
mi.Invoke(ad, new object[] { LoaderOptimization.SingleDomain });
A good place to do that would be in the app startup code.
A slightly less dangerous approach would involve creating a new AppDomain, which would inherit all setup properties from the current one but LoaderOptimization, which will be set to SingleDomain, and running the UWP dependent code in that domain. Like this:
AppDomain CreateUnsharingDomain()
{
AppDomain cad = AppDomain.CurrentDomain;
AppDomainSetup cads = cad.SetupInformation;
return AppDomain.CreateDomain("Dummy", cad.Evidence,
new AppDomainSetup
{
ApplicationName = cads.ApplicationName,
ApplicationBase = cads.ApplicationBase,
DynamicBase = cads.DynamicBase,
CachePath = cads.CachePath,
PrivateBinPath = cads.PrivateBinPath,
ShadowCopyDirectories = cads.ShadowCopyDirectories,
ShadowCopyFiles = cads.ShadowCopyFiles,
ApplicationTrust = cads.ApplicationTrust,
LoaderOptimization = LoaderOptimization.SingleDomain
});
//Not sure which other properties to copy...
}
CreateUnsharingDomain().DoCallBack(MyUWPDependentMethod);
Again, it would make sense to create the domain once and cache it for the app lifetime.
This approach might be faster than the one with the monkey-patched AppDomain. The MultiDomain optimization exists for a reason; if you leave most of the Web code in a MultiDomain world, the optimization will do its work as intended.
Inspiration: "Walkthrough: Using WinRT libraries from a Windows Desktop application" by David Moore.
I have a classic ASP application written many years ago that I'm trying to fix.
The following lines recently stopped working after w7 sp1 was applied.
set address = Server.CreateObject("ADOR.Recordset")
count = lo_connection.GetRecordset(sql,address,false, error)
Set RDF2 = Server.CreateObject("RDSServer.DataFactory")
Set teststring = RDF2.ConvertToString(address)
It fails on the last line there saying "Microsoft VBScript runtime error: Class doesn't support Automation"
A bit of searching found several articles like this one
http://blogs.technet.com/b/asiasupp/archive/2011/03/14/changes-in-mdac-adodb-com-components-in-windows-7-service-pack-1.aspx
that described the problem exactly. Where I am failing is that none of the suggested fixes seems to fix the problem. Any suggestions?
The solutions described in the link are not relevant here, since ASP is not early-bound - it uses OLE Automation. It might be worth re-registering the component which creates RDSServer.DataFactory objects (which is C:\Program Files\Common Files\system\msadc\msadcf.dll on my machines).
I looked up this object, and I found this Microsoft web page:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681447(v=vs.85).aspx
"This feature will be removed in a future version of Windows. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Applications that use RDS should migrate to WCF Data Service."
Doesn't sound too good.
I am developing DotNetNuke modules and naturally want them compiled before installing or distributing them. In the past I've simply referenced a specific version of DotNetNuke.dll by browsing to the /BIN folder of a local DotNetNuke installation.
This reference allowed me to use the DNN base classes and create my own set of classes upon those. I also use various helper methods throughout the DNN namespaces/classes that I require. (i.e. Make derived classes from their PortalModuleBase, ModuleSettingsBase and use their Localization classes which replace those provided by Microsoft's ASP.NET implementation.)
I've been able to get away with this approach making that direct DLL reference (Copy Local = True, Specific Version = False) because until now I've been installing these modules onto client websites that I maintain. As such, I've kept them on at least the version of DotNetNuke I've been developing on - or newer. Most recently, I was referencing 6.1.3.108 in development.
NOTE: This automatically copies in the following associated DLLs into the /BIN directory of my modules:
DotNetNuke.dll
DotNetNuke.Instrumentation.dll
dotnetnuke.log4net.dll
DotNetNuke.Services.Syndication.dll
DotNetNuke.Web.Client.dll
DotNetNuke.WebControls.dll
DotNetNuke.WebUtility.dll
Installing this onto a DotNetNuke site of a NEWER version worked fine, which isn't a bad start.
What I've been wondering though, is if there is a non-hackish way of making my modules insensitive to the minor, build or revision levels of the DLL?
I realize that it makes it my responsibility to ensure the product (if developed on a "mid range" version) still works on slightly earlier as well as newer versions of the product. That said, I feel I can do thorough testing across those builds. To me this is preferential to having to run the OLDEST major build in development.
Put another way, I'd rather not develop with references to 6.0.0.0 just so it works on 6.x.x.x without extra effort. I'll only do that if someone doesn't have a brilliant way for me to make referencing say, 6.1.3.108 working on slightly earlier or later versions. (Naturally I'm okay with having to make a different module for major version changes, such as 5.x.x.x or 7.x.x.x.)
Thanks in advance!
Instead of referencing the assemblies in the bin folder, keep a copy of DotNetNuke.dll (and any other references) with your source code, and reference it there. Put the oldest supported version there, but develop on a newer site. Set Copy Local=False on the reference so you don't overwrite the newer version, and you should be fine.
In this way, we're able to reference DNN 4.5.3 while developing a module that runs on DNN 6.1.x. I've been using this method for years without any significant problems (except when I occasionally forget to turn off Copy Local and my DNN site mysteriously blows up).
In regards to determining the version of DNN in a class you've subclassed from a DNN one.
Here's what I would do, assuming YourClass inherits from DNNClass, but because you have referenced an earlier version of a property, 'NewProp' doesn't exist. Here's how to do it:
public class YourClass : DNNClass
{
public string NewPropSubstitute
{
get {
string newPropVal = "your default if earlier DNN";
System.Reflection.PropertyInfo pi = this.GetType().GetProperty("NewProp");
if (pi != null)
newPropVal = (string)pi.GetValue(this, null);
return newPropVal;
}
}
}
That's a made-from-memory guess so it might not compile, but you get the idea. You don't necessarily have to get the DNN Version if you want - just try and get the property through reflection - if it's there, implicitly you've got the right version.
Of course this method assumes you can substitute in a value for a later-DNN property (or method) if the DNN version doesn't support it. But that all depends on what you're trying to do.
If you do want to find the DNN Version (version safe and always correct) you can use the code for that which is embedded in my version-safe jQuery inclusion code, linked from this blog post:
Using jQuery in DotNetNuke 5 and 6
I have an XBAP currently published on my local machine, which has an 'About' canvas build into the XMAL, of which I want to show the published version number, but I can only seem to get the assembly version number. Any suggestions?
First make sure you add the following assembly to your project references: System.Deployment. Then you can access the current version like this:
using System.Deployment.Application;
...
if (ApplicationDeployment.IsNetworkDeployed)
VersionTextBlock.Text =
ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();
CurrentDeployment is null when you debug locally, so you can use IsNetworkDeployed to only retrieve the version info when you run from the published location.
With .NET 3.0 I'm using
Version ver = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
I've seen somewhere saying to use:
System.Deployment.ApplicationDeployment.CurrentVersion
But when using System.Deployment there appears to be no System.Deployment.ApplicationDeployment available to be accessed!
This may not be a solution but may point in the right sort of direction. If someone uses this already maybe they can shed some more light on the matter.