Why do I need to deliver DevExpress.Printing.v14.2.Core.dll - devexpress

I have implemented a WPF application using DevExpress controls.
When I was finished, I optimized my references in Visual Studio (using Resharper). I have the following references left:
DevExpress.Data.v14.2.dll
DevExpress.Mvvm.v14.2.dll
DevExpress.Xpf.Core.v14.2.dll
DevExpress.Xpf.Grid.v14.2.dll
DevExpress.Xpf.Grid.v14.2.Core.dll
DevExpress.Xpf.Ribbon.v14.2.dll
When starting the application on a clean OS, it crashes. With Process Monitor, I find that it is looking in 10 different places for DevExpress.Printing.v14.2.Core.dll and cannot find it.
That DLL is 3 MB in size and I'd like to avoid to deliver it, if possible.
Dependency walker seems to not work well for .NET.
I have read DevExpress about required libraries, but that is for XtraReports, which I'm not using in my application.
Why does my application look for that DLL if it is not referenced?

Found the answer using JetBrains dotPeek:
DevExpress.Xpf.Core.v14.2.dll and DevExpress.Xpf.Grid.v14.2.dll both have a reference to DevExpress.Printing.v14.2.Core.dll.

Your application contains the DXGrid. Thus, according to the DXGrid's required Redistributable Assemblies list, the DevExpress.Printing.v14.2.Core.dll assembly contains classes that allows to implement the functionality for DXGrid's printing and exporting based on DXPrinting library.

Related

How to use .NET 6-windows and .NET 6 targets in one library

I've segregated my WinUI 3 application into different layers: Application, Infrastructure, Presentation etc.
And all the projects have targets: net6.0-windows and I want to move it to the Uno Platform.
So, I've added a new target: net6.0
And at this moment the problem arises:
Type [WinUI] component already defines a member, called InitializeComponent or some problems with binding.
Is it possible to make such type of library with targets to net6-windows and net6.0?
For the Windows app project itself, you need to use net6-windows, as that provides additional dependencies specific to Windows app projects. All other libraries (non-app projects) can then use net6.0.
Regarding the specific error message, you are getting, the reason might be the generated files have some kind of conflict - you can try deleting the obj and bin folders and rebuild.
The easiest way to make existing Windows app support Uno would probably be to create a blank Uno solution and then migrate the code there (as the solution has already the required setup for platform-specific projects prepared and you can then just add your code.
Uno also provides templates for cross-targeted libraries, so you might be able to use similar approach. The one linked is for "UWP" solution however, so to make it WinUI, you would need to switch from uap10.0.18362 to net6-windows.

UWP API in ASP.NET

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.

Satellite assembly is not picked up by ASP.NET app

I have a web project called "TestResourceApp" with Labels.resx in App_GlobalResources folder. I want to add another language by creating a satellite assembly.
Here are the steps I took to create the satellite assembly. The default text always get displayed. What did I do wrong ?
1) Create Labels.fr.resx in a different folder.
2) Generate resource file:
Resgen Labels.fr.resx TestResourceApp.App_GlobalResources.Labels.fr.resources
3) Generate satellite assembly:
AL /t:lib /embed:TestResourceApp.App_GlobalResources.Labels.fr.resources /out:french.dll /c:fr
4) Copy french.dll to TestResourceApp/bin/fr
I have uiculture set to auto in web.config and I have change the language on the browser.
I was able to use this page to solve some satellite assembly issues I was having. I'll throw in a few more things to check.
It's helpful to decompile the "neutral" assembly and see how it's put together. A tool like ILDASM.exe is helpful for this purpose. Once you get it decompiled, look through the text output for ".mresource", and you should see one with your naming. For example, if you add a resource to a Visual Studio project, they're named MyAssemblyName + ".Properties.Resources" + a language (if any) + ".resources" Examples:
MyAssembly.Properties.Resources.resources (neutral language)
MyAssembly.Properties.Resources.en-US.resources (English (US))
In my case, I had the file named properly, and in the appropriate folder (such as Bin\en-US). I was able to verify that much by using ProcMon.exe (by the SysInternals guys) and could see the worker process finding and reading in my DLL file (instead of just saying "PATH NOT FOUND"). However, it was not finding the resource by the name that it expected it to. That's when some disassembly helped to get to the bottom of the naming problem.
So, use ProcMon.exe to narrow down the kind of problem you might have. Hopefully that's helpful to someone.
It's complicated but here are a few tips for those who run into this problem:
Try to include the resx in the web project and let VS do the job for you.
Reflector is your friend. Compare satellite assemblies you created and those created by VS.
If you web app is targetting ASP.NET 2.0, you should use Resgex and AL that come with .net 2.0. Open the assemblies in Reflector and check the "references". It should reference mscorlib version 2.0.
If you deploy your web app using web deployment project, make sure the namespace for the resources in your satellite assemblies is correct. Again, compare with what VS creates. In my case, I used the wrong tool to generate the designer.cs file because I wanted them to be accessible from a different assembly. Make sure you are using GlobalResourceProxyGenerator. Otherwise, the namespaces won't match and the deployment code will not be able to find your resource. The namespace in the designer.cs should simply be "Resources", not "XXXX.App_GlobalResources"
Did you have set enableClientBasedCulture to true in globalization ?

What makes an ASP.NET project an application vs library?

I am inheriting some ASP.NET code (I am an OS guy, not a web dev (yet ;-)). The solution has been re-factored and there are multiple projects (libraries and asp.net sites) in it. Aside from the libraries, there are two asp.net projects (called MAINSITE and SUBSITE). Only MAINSITE is being used as the official site (as an asp.net site), and MAINSITE has a depency on the code in the SUBSITE asp.net site, but doesn't use the site itself. I am trying to figure out how to clean this up and convert SUBSITE into a library.
My quick question is, whenever I debug the MAINSITE (set as default), it runs two asp.net processes: MAINSITE and SUBSITE. And so, at the very least, how can I avoid this? Is there a quick/temporary solution to this?
My detailed question is this:
What makes an asp.net site an asp.net site? For instance, in C the difference between an dll and exe could be defined (superficially anyway) as the presence of a main, and potential export information for the library (among other things, of course). If I were to convert an exe to dll I might:
1. remove the main code
2. make sure the public interface was correct (and exported correctly)
3. convert the makefile to build a dll rather than an exe.
Can someone point me to some similar steps for asp.net to .net lib?
Maybe:
1. get rid of index.aspx
2. get rid of web.config
3. any *.cs files to remove?
4. how do I change the properties?
5. any gotchas?
Thanks so much for your help.
Details: Visual Studio 2008/.NET 3.5
There are many, many components to make an application run as an ASP.Net application. However, in terms of your actual Web Application project, there's really not that much difference between it and generic library code except for the fact that much of your code relies on the existence of the HttpApplication runtime.
Any code that utilizes the System.Web (especially System.Web.UI) is going to be suspect in terms of having this dependency. For example, all the code in page or webcontrol event handlers (Init, Load, PreRender, etc.) relies on the fact that there is an HttpHandler (running inside an HttpApplication) raising these events. If you run the same WebControl out of a library that's not in an ASP.Net project, none of this will ever happen and the control will be useless. However, that exact same library would be quite functional if executed in the context of an ASP.Net process.
It really boils down to what process you're running the library in. In most cases, ASP.Net processes are spawned by IIS, although it is possible to host an ASP.Net process in other types of programs as well.
There isn't a simple 5-step process for converting a web project to a library unfortunately. But as a rule of thumb, webcontrols, .aspx and .ascx codebehind aren't going to convert.
For a more detailed look at what makes code into an ASP.Net program, see Rick Strahl's "A Low level look at ASP.Net".
If you go to "File" > "New" > "New Project..." and then click on the (assuming you're using C#) "Visual C#" in the list on the left, you're given the ability to create a "Class Library" project. You can extract all the relevant code to one of these and then reference in in your "MAINSITE".
You will need to reference it in the "References" section of your MAINSITE project and may need to import your library project using the import keyword.

In Flex, is it posible to identify if the code is runing on Web or AIR?

I'm coding an app that runs both in the web and on AIR, to avoid copying code arround, I figured I should do 3 kinds of projects on flex builder: Library, Web and AIR projects.
So all my code is on the Library project.
I have accessData.as that extends EventDispatcher to fetch web services and return them as an event. I plan on using this class to also fetch SQLite data for the desktop version, but to do so I need it to decide from wich source to get the data depending on if its Web or AIR.
Anyone know how to do this?
Please refer to this link Detect AIR versus Flash Player from an actionscript library Its more detailed.
You really should have two build targets, one for Web and one for AIR. And your code should be designed in a way that the rest of the system doesnt care what the implementing part is doing, only that it conforms to a certain interface. This way, each build simply replaces the implementing code for each desired platform.
You may find something useful under System or Capabilities in the docs.
Create 2 projects Air and Standalone and create 2 conditional compilation variables for example "standalone" and "air". (more here).
Go to Project->Properties->Flex Compiler and add
For air project:
-define=CONFIG::standalone,false -define=CONFIG::air,true
and for stanalone:
-define=CONFIG::debugging,true -define=CONFIG::air,false
In your code set:
CONFIG::standalone {
trace("this code will be compiled only when air=false and standalone=true");
}
CONFIG::air {
trace("this code will be compiled only when air=true and standalone=false");
}
umm... I just found out a way
var appName:String = Application.application.name;
this works since the web version is called "" and the desktop version is called " desktop"
but if anyone has a better way please go ahead.
thanks.

Resources