I am working with Spire.PdfViewer for a WPF Application.
After downloading the package, the Spire.PdfViewer.Wpf.dll should be found in the bin folder of my project. Unfortunately I'm not able to find the library on my network.
The documentation is found under this link:
http://www.e-iceblue.com/Tutorials/Spire.PDFViewer/Demos/Quick-guide/WPF-How-to-add-Controls-to-Toolbox.html
Thank you
According to the description for Spire.PDFViewer NuGet package on the official site, it mentioned that “With Spire.PDFViewer, developers can create any WinForms application to open, view and print PDF document in C# and Visual Basic on .NET”. It is a free version for .NET.
For the version for WPF, you need to buy download the Spire.PDFViewer Pack from below link, which contains Spire.PDFViewer for WPF components.
http://www.e-iceblue.com/Introduce/word-viewer-wpf-introduce.html#.V8Uzrih94z4
After installing, please choose the Spire.PdfViewer.Wpf.dll from C:\Program Files (x86)\e-iceblue\Spire.PdfViewer\Bin\WPF4.0. Then you can add PDFViewer controls into Toolbox.
Related
Attempting to create nuget package to upload to our own nuget sever, and would like to eliminate the manual process of creating and editing the nugspec file. Everything I've read, says the setting can be pulled from the project file (if using package reference). And that the settings exist on the Package tab of the project properties window. But that tab is not there.
Using vs 2019, .NetFramework 4.7.2, project is a library, and has been migrated to package reference.
I took an existing project, right clicked the references, and used the migrate option. Package tab is non-existent
I also set the nuget package manager to default to packageReference, and create a new class library.
Package tab also non-existent
The required package (when using non-SDK Style with package reference) nuget.build.tasks.pack has bee added to the references of both projects mentions
Any help would be appreciated
The package tab is only available for SDK style projects. Non-SDK style projects use a different project system in Visual Studio, which doesn't contain that project properties tab. The new project system (on github, the old one is closed source) was initially made to look the same as the old project system, but slowly they're diverging. The Reference/Dependencies node in Solution Explorer is one obvious example, as is the Package tab in the project properties window.
To create the MSBuild properties used by pack, you'll need to manually edit the project file as XML. Within Visual Studio, you need to right click the project in Solution Explorer, select "unload project", now when you single click the project, or right click and select edit, you'll see the project XML. Once done, right click the project again and select reload project. Alternatively, edit it with a text or XML editor outside of Visual Studio, and Visual Studio will detect the change and prompt you to reload the project when you alt-tab back.
My suggestion, however, is to convert your non-SDK style project to an SDK style project. "Standard" class library projects work fine, and I'm not aware of any disadvantages (unless some developers on your team are using Visual Studio 2015 or earlier still), given the non-SDK style project is already using PackageReference. Some other project types might have limited Visual Studio experiences when targeting .NET Framework in an SDK style project. Other project types might not be compatible with SDK style projects at all. However, most people creating NuGet packages are doing so with standard class library projects, which shouldn't have any problems.
There is a "unsupported" tool try-convert to convert non-SDK style projects to SDK style. Personally, I just delete the csproj, create an empty directory, run dotnet new classlib on the console, move the csproj to my existing project's directory, rename the project file, and delete that temporary/empty directory. If you have anything other than .cs files in your project that need explicit entries in the csproj, hand edit the csproj if you're comfortable with msbuild, otherwise load the project in Visual Studio and use the Solution Explorer and Properties windows.
Some people believe that SDK style projects are only for .NET Core or .NET Standard. That's not true, but unfortunately the Visual Studio new project templates give that impression. You will need to create the class library project targeting .NET 5, .NET Standard, or .NET Core. But once the csproj is created, edit the csproj (with SDK style projects it's no longer necessary to unload the project) and change <TargetFramework>net5.0</TargetFramework> to <TargetFramework>net472</TargetFramework>. Another advantage of SDK style projects is it's easy to multi-target, a useful technique to slowly modernize your projects to newer runtimes. Add an s to the XML element name to make it plural, and add extra target frameworks as a semi-colon delimited list <TargetFrameworks>net472;net5.0</TargetFrameworks>. When changing between TargetFramework and TargetFrameworks, Visual Studio should prompt you to reload the project, but I found that it still has some issues. So I suggest closing the solution and opening it again, then everything should work great.
Adding MVVM Light reference to a WPF projects adds a large number of system assemblies to the list of dependencies in the accompanying MSI Setup project. These assemblies (50+ in number) are then copied to the application folder when the app is installed. Why is it so? Why can't it reference it from GAC directly?
Note: Copy Local option is set to True for MVVMLight.dll. I obviously can't set it to False.
Reproducing it is extremely simple. I'm using VS2015 Community.
Create a new WPF Application project.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (must have the extension installed).
Add Primary Project Output of WPF application to the setup project.
There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
Why? And how to fix it?
Update
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.
I don't know why it happens but I can offer a workaround. Just open the project's Detected Dependencies folder, select all of the System dlls, right-click and select Exclude.
Overly agressive dependency scanning is one of the many reasons I don't use Visual Studio Deployment Projects. Instead I use WiX / IsWiX. Both open source and the later written by myself.
For more information see:
http://www.github.com/iswix-llc/iswix-tutorials
I want to refer to evengaggregator in my project and cannot find microsoft.practices.composite library easily. I could not find that in reference and tried few installation but no luck yet. I am using .net 4.0. Could you please help me to get start on how do I get microsoft.practices libraries on my machine? I am new to WPF and trying to join the dots here.
Thx,
Nikunj
Open below link and download prism library.
http://compositewpf.codeplex.com
after downloading go to Lib folder of downloaded prism and add reference of DLL to your project as required.
I am authoring a management pack with custom views using Silverlight / WPF (shared code) and MP authoring console and MP authoring tool in Visual Studio.
I am following this tutorial on custom views.
Widget for SCOM operation and web console - custom
In Section 4.1: It mentions: Add a reference to Microsoft.EnterpriseManagement.CompositionEngine and Microsoft.EnterpriseManagement.Presentation.Core assemblies. These can typically be found in the Console folder of the Operations Manager installation. Attention: the assemblies from the RTM/CU1 installation will not work! You need to download the sample project files and use the included assemblies.
I cannot add references to the Silverlight project. I get an error message:
Is there any way to get around this?
I understand that the .net runtime is different than that of Silverlight. Yet, this tutorial shows a working example, so it there a missing step or a different binary. What am I missing?
In Section 4.1: It mentions: Add a reference to Microsoft.EnterpriseManagement.CompositionEngine and Microsoft.EnterpriseManagement.Presentation.Core assemblies. These can typically be found in the Console folder of the Operations Manager installation. Attention: the assemblies from the RTM/CU1 installation will not work! You need to download the sample project files and use the included assemblies.
The important bit is the bit in bold, you need to download the sample project and copy the references from there. Were you doing this?
http://gallery.technet.microsoft.com/Creating-a-Widget-for-104711ac
If you download this zip and go to the following sub directory
\Creating a Widget for Operations Manager Dashboard - Walkthrough %231.zip\Creating a Widget for Operations Manager Dashboard - Walkthrough #1\Section_4\AlertSummarySilverlight\Bin\Debug
You'll see the two assemblies in this folder. Copying them out of the zip into another folder and add a reference to them. This works for me in Silverlight 5.
I want to pack my file in to a single executable file "setup.exe", my application is written in c# and WPF, I know that there are a lot of applications out in the store for creating a installation pack, but the point is which one would help me to build my installation pack just like Devexpress dose ?
For an UI similar to DevExpress you will need a setup authoring tool which offers an external UI and rich graphics.
Advanced Installer and InstallShield have some great UI themes which can get you started. You can also find a list of setup tools here:
http://en.wikipedia.org/wiki/List_of_installation_software
You'll probably have to roll a custom solution for this one. I expect nothing less of the Devexpress team then creating their own installer.
If you're application is not heavily bound into the registry and all kind of windows folders it should not be that hard to create an application that extracts some files into a directory and create some great UI while copying.