I inherited this project that used NAudio 1.7.1.16.
In there they use SignalGenerator.Frequency1 and SignalGenerator.Frequency2 to generate a TwoTone sound.
However, the later version 1.7.2 and latest 1.7.3, Frequency1 and Frequency2 and SignalGeneratorType.TwoTone does not exist any more!
So how do I do the TwoTone thing with the latest version of NAudio?
You must have inherited a custom build of NAudio. NAudio's SignalGenerator has never had a TwoTone option. It has been unchanged ever since it was added in 2012.
Related
I have an app that runs perfectly without new dependencies like this one:
A newer version of androidx.navigation:navigation-fragment-ktx than 2.4.2 is available: 2.5.0
If I upgrade to v.2.5.0, my app has warnings about unrelated elements like for example references to menu objects.
Should I wait and allow these Gradle warnings such as above notice until another upgrade comes along and try the new dependency then?
You shouldn't need to update anything unless you have a reason to. It's often a good idea (as well as new features you also get bug fixes) but it's usually not required. Specifying all your dependency versions means you get a repeatable build that should always work, so long as those versions are available
The thing about libraries is they often have dependencies on other libraries, and updating one might introduce a requirement for other stuff to be updated (which might be why you're seeing other errors appear. That broadly shouldn't happen (making things independently updateable is part of the reason for breaking everything out into separate libraries!) but here's a blog post from when they introduced it:
Starting with the AndroidX refactor, library versions have been reset from 28.0.0 to 1.0.0. Future updates will be versioned on a per-library basis, following strict semantic versioning rules where the major version indicates binary compatibility. This means, for example, that a feature may be added to RecyclerView and used in your app without requiring an update to every other library used by your app. This also means that libraries depending on androidx may provide reasonable guarantees about binary compatibility with future releases of AndroidX -- that a dependency on a 1.5.0 revision will still work when run against 1.7.0 but will likely not work against 2.0.0.
Really you have to look at the release notes for a library to see if there are any breaking changes you need to worry about. For example, here's the one for the Activity Jetpack component and if you search "dependency changes" you'll see where updating actually requires a specific minimum version of another thing
Also sometimes a library will pull in an old version of another library it depends on, so you might be explicitly interacting with a very old version of a component just because you never added it as a dependency yourself. Then if that first library requires a much newer version of that dependency, you might suddenly get a large jump that requires a bunch of changes to your code, even though it doesn't seem to have anything to do with what you updated!
I´d like to compile an dll in ironpython AND add some information on the file-version. In former versions (e.g. 2.7.7) there has been the theoretical possibility to do this by
ipy.exe pyc.py test.py /out:test /file_version:1.1.1.1 /target:dll
In newer versions I can´t see the feature (/file_version) anymore (also not in ipyc.exe, which is shipped with ironpython). Does someone know the way?
I found the feature. At least in the versions 2.7.11 and 3.4.0alpha I found the feature in ipyc.exe
ipyc.exe /out:dummy.dll /copyright:dummycopyright /fileversion:1.1 /productname:dummy /productversion:1.1 <skripts>
Unfortunalely, it is not documented in
ipyc.exe /h
I was looking there for the feature, that´s why I raised the question.
Well, I prefer hidden features to hidden bugs. ;)
I am currently wrapping my head around NuGet-packaging and how, for me, to best use them.
I recently made a NuGet-package of a class library with including dll-assemblies and that worked just fine.
Now I would like to seperate the two so that for every new version of dll-files i pack I want to ALWAYS reference those to the newest version of the class library.
Is there any way to go about this?
I got a warning while building my xaml project:
The type ‘SvgImageSource’ is not available in the target platform
minimum version (10.0.14393.0)
I understand that I'm getting this because 14393 does not have an SvgImageSource control.
I still want to use the control and I also want to support 14393. Is that possible? Is there a way for me to create an alternative control for the older version?
This will be possible starting from the Creator's Update (15063) with Conditional XAML.
Conditional XAML provides a way to use the ApiInformation.IsApiContractPresent method in XAML markup. This lets you set properties and instantiate objects in markup based on the presence of an API without needing to use code behind. It selectively parses elements or attributes to determine whether they will be available at runtime.
I suppose you're using the control for SVGs. If you really need to run on older Windows 10 versions, have a look at this post from Igor Ralic on the Mntone.SvgForXAML library. That will be a lot easier than trying to create the control yourself.
Extra note: if you're still working on the app and are not releasing in the next few weeks, then it might be an option to skip straight to the Creator's Update. Already over 65% of the devices are on 15063 or higher in August and it's raising every week.
guys,
I have the following case: I want during the major upgrade to preserve the version of the product being upgraded (e.g. if I am upgrading from 1.1 to 1.2, to save the value 1.1) and to run an executable passing this version as a parameter, after the install of the new product finishes. This will mean that I will call this somewhere around InstallFinalize. I found this very helpful article for my case: http://blogs.technet.com/b/alexshev/archive/2008/02/21/from-msi-to-wix-part-5-custom-actions.aspx
The problem that I experience is that I don't know and can't find an explanation on when will the property be set. When will this registry search be executed. Am I going to set this property once on the start of the upgrade or is it going to be set dynamically when the property is being invoked?
If you're using the WiX major upgrade element, this should work with AllowDowngrades set to yes. There's no need to manually try to set a version somehow. See here:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
where it says "AllowDowngrades already allows two products with the same version number to upgrade each other."
Definitely try this before trying to run code. Note that the ProductVersion property isn't "set" - it's in the MSI file and is transferred to the system from there.