If I add the RX-main package to a WPF application I get the following dependent packages installed:
Rx-Interfaces
Rx-Core
Rx-Linq
Rx-PlatformServices
Rx-Main
After adding Rx-main there are two additional packages related to WPF that can be installed
Rx-XAML
Rx-WPF
Rx-Xaml is dependent on Rx-Main, and Rx-WPF is dependent on Rx-Xaml. However both of these packages add a reference to System.Reactive.Windows.Threading. What if anything is the difference between them, and why are there two separate packages that add a reference to the same assembly?
Also, do I need to add either or both to be able to use RX in WPF?
I actually know the answer to this, as the former owner of the Rx-Xaml package. It used to be that there were only Rx-Silverlight and Rx-WPF. This made it difficult to create packages like ReactiveUI, since they had a dependency on one or the other depending on which platform you're using.
So, I created Rx-Xaml, which was literally just a merging of Rx-Silverlight and Rx-WPF. However, the Rx team realized that having separate packages was silly, and asked me if they could take over the name for themselves. I gladly obliged, and now Rx-Xaml is the package you should be using. Rx-Xaml since 2.0 is owned by Microsoft.
tl;dr: Use Rx-Xaml, ignore Rx-WPF and Rx-Silverlight, they're old and busted.
From what I see using NuGet Package Explorer, neither Rx-WPF not Rx-Silverlight include any DLL of their own (or any other file, as a matter of fact) in their respective nupkg files. Therefore they seem to function only as a container for Rx-Xaml. My guess is that you should still point to Rx-WPF since the Rx team might start adding specific logic to it which would not be contained in the base Rx-Xaml package.
Related
I am trying to install/add manually the *.jl-master.zip files, I am doing this because I have a computer without access to internet but I don't know how to do the offline installation.
The version of Julia is 1.3.0 and the O.S. Windows 10
I had tried this,
Instruction I followed
but for me It does not work.
Thanks
Regards
Installing Julia packages offline is very difficult due to the fact how binary dependencies work.
You have basically two options:
buying JuliaTeam/JuliaPro from Julia Computing (maybe someone who is using it will ever see that thread and could share their experience?)
hacking
Regarding the second option the best bet is to install all required packages on a different machine having and copy the .julia folder to your offline machine (or, depending on your configuration folder referenced by the JULIA_DEPOT_PATH system environment variable).
However, in most cases you will need to rebuild several packages. The problem is that Julia packages have several binary dependencies that come from different sources. This problem has been noted by the Julia community and is being addressed by the Julia Artifacts mechanism.
Today the most common step is to manually edit deps/build.jl file in each Julia package that is downloading binary resources in its build process and make the build code to point to files in your local repository. Once done you can rebuild the package offline by running using Pkg;Pkg.build("PackageName").
I would like to override the default powershell scripts that come with win_chocolatey module of Ansible. How do I do that?
In my case, I am trying to override the ChocolateyInstall.ps1 that comes with MsSqlServerManagementStudio2014Express. I would like to pass a few more parameters such as system administrator password and instance names during the silent installation of MsSQLServer.
I have tried giving these additional parameters with "install_args" and "params" options in win_chocolatey module call in my ansible playbook. But there are no handlers written in MsSqlServerManagementStudio2014Express's powershell scripts to include them during silent installation.
Package Parameters vs Install Arguments
Install Arguments (--install-arguments option for choco.exe) are completely invisible to the packaging, and they are appended to the current set of silent arguments in the package. One can also override them completely with --override-arguments. In the commercial editions of Chocolatey, you can also pass --install-arguments-sensitive to keep secrets out of logs.
Package Parameters (--package-parameters|--params) are different, can be used with anything related to packaging (not just for the installer), but must also be present in the packaging itself. For commercial editions and secrets, you also have --package-parameters-sensitive.
Option 1: Community Repository Packages
You would need to ensure that the package is using Install-ChocolateyPackage, Install-ChocolateyInstallPackage, or other built-in methods to know that install arguments can be used with the package. If you need parameters, you will need to work with the maintainers of the package to get those implemented.
Option 2: Use Your Own Packages
If you are using Chocolatey in an organization, you will want to use your own package you store somewhere internally. That guarantees much more reliability and repeatability, something that is instrumental to organizational use of anything.
Plus you can bake installers directly into the package as you are not subject to distribution rights internally, providing an even more reliable experience.
It is especially helpful to read over and understand this when planning for Chocolatey in an organization: https://chocolatey.org/docs/community-packages-disclaimer
I have a large win32 program consisting of a mixture of native and managed code.
I would like to put it into a single .Appx file for simple installation on Windows 10. I don't want to put it in the Windows Store - I simply want to replace the old installer with an .Appx file.
Using the DesktopAppConverter I have converted the program to an .Appx.
My problem is that the DesktopAppConverter adds a dependency on 'Microsoft.VCLibs.140.00.UWPDesktop' which means that I have to distribute both my .appx and Microsoft.VCLibs.x64.14.00.Desktop.appx. So the user can no longer just click my .appx file but has to run this from PowerShell:
Add-AppxPackage .\MyApp.appx -DependencyPath .\Microsoft.VCLibs.x64.14.00.Desktop.appx
Is there a way that I can "merge" the dependency into a single .appx that the user can just double click to install?
Microsoft documents support for appx bundles, you could try that.
Another option, more risky, would be to assume that such a dependency is already present on the machine (it is quite common so it might be installed by other packages from the store). In this case you can edit your appx package and remove the dependency from it.
Advanced Installer can import appx packages and provide an easy to use GUI to edit their content, with just a few clicks you can remove/add your dependencies.
Advanced Installer UWP support - dedicated GUI editor for package contents, convert from old MSI/EXE to UWP, create UWP and WSA packages...
Disclaimer: I am part of the team building Advanced Installer over the last 14 years.
I'm trying to create setup for my project. I added the new project with "Setup . When I add primary output to the project, I got the following warning.
"The following files may have dependencies that cannot be determined automatically. Please confirm that all dependencies have been added to the project C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\Ltocxu.ocx C:\Users\admin\AppData\Local\Apps\2.0\OPJL9CEH.K72\TOHQTNEM.N1Q\weba..tion_5eaf22060995d42c_0001.0000_b98a6abda035b9be\LeadTools\LtocxVariantu.dll
Please guide me to solve this problem.
Thanks in advance..
This warning is a "general" warning and not one that may necessarily stop the software from working. It only means that since OCX and DLL files are older technology, the new setup project may not be able to detect the dependencies for these files. You may want to check the LeadTools documentation or find the dependencies manually and add them to the distribution as required.
Again, since this is a general warning for the tool (setup project) itself and not your project specifically, even if you add any missing dependencies.
In this particular case, the warning might be valid. The old LEAD Main OCX (Ltocxu.ocx) did require additional DLLs to work. Some of them are directly linked as dependencies like the kernel and display DLLs (LtKrnu.dll and Ltdisu.dll).
Others are dynamically loaded if needed, such as file format DLLs.
You should be able to find full details in the topic "Files to be Included with Your Application" in LEADTOOLS help files for your specific version of the toolkit.
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.