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?
Related
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.
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.
Regarding to the solution described in this post, a third assembly is required to forward the type resolution to the correct assembly.
When adding this reference to the Android class library project using the type, the forwarding seems to not be done. The reference needs to be added in the Android application project which is the end point of the build process.
Does any solution exist to add the reference embedding the forwarding in the project requiring it ?
I mean, if in my solution architecture I use :
MyApp.Core - PCL
MyApp.Core.Droid - Android class library
MyApp.UI.Droid - Android Application
The usage of System.Net namespace (System.Net.Socket.AddressFamily for example) is done in my ViewModel, which is located in MyApp.Core.Droid (redirection of MyApp.Core with some plugins). In this case, it is more logical (and readable) to have the reference in the MyApp.Core.Droid. But in the fact, the assembly resolution is done (from what I understand) when packaging the application, so in MyApp.UI.Droid. So in this case, the reference needs to be added to MyApp.UI.Droid in order to be found (failed if added to MyApp.Core.Droid).
In this case the solution works, but its quite obvious to understand for a new programmer joining the team which, has not been facing the trouble and understands why this reference needs to be added to the UI project...
I'm not sure my thought is easy to understand by the way I introduce it. Let me know if you need more explanation.
Thanks,
Guillaume.
I'm not entirely sure why this 'fails if added to MyApp.Core.Droid' - it feels like this should be added. However, I know that Xamarin have tweaked and changed the dependency resolution scripts a few times.
With that said, I think the best answer to your question is 'don't worry about it too much' - this is only a small inconveneinve right now and it will be resolved by Xamarin's updates 'soon'.
The current PCL support is something that I and a number of others have worked on in order to make things work. This set of 'hacks' is a workaround for the lack of 'proper PCL' support - it simulates what the Microsoft PCL build platform does on WindowsPhone, WPF, etc, but it isn't a perfect implementation.
Xamarin have now committed to 'proper PCL' support. When that happens then these type-forwarding dependencies will automatically be added. The good news is that this support is perhaps now only days, weeks or at most months away.
Where do you store your old classes and files, which you don't longer use in a current project?
I have quite a few classes and files, which are no longer required, but which I would like to keep somewhere in case I need to reuse some of the code later.
Currently, I am just copying and pasting the code in a tool called Code Collector Pro.
However, since this seems not to be the most elegant way of storing old code, I would like to ask you: How do you save your old code?
If you are talking about handy snippets of code that you might use often I store them in Xcode's Code Snippet Library (just drag selected code in to create a snippet.)
Generally though, I delete unused code. If I need it again it will be in my version control system.
I would definitely use a version control system (I'm most familiar with Subversion, but am getting into Git now). If this is code that's worth keeping around then it's code you'll likely use and modify in multiple projects over time. You'll want to be able to review the history of your changes, compare how you used it differently in project A vs. project B, and maintain notes to help refresh your memory and to help in keyword searching when you're trying to find that bit of code you remember using two years ago.
You can set up repositories however makes sense for your work - by project, by code type, etc.
I'm not familiar with Code Collector Pro - if it works as a GUI for a version control system, it may be fine for what you're doing.
I've been trying to use the JFace ProjectionViewer to implement folding in a standalone Java app. I got the idea from this article:
http://www.eclipse.org/articles/Article-Folding-in-Eclipse-Text-Editors/folding.html
However the source code provided with the article is for an Eclipse plug-in, not for a standalone.
The particular problem I'm having is that I can't get the VerticalRuler to respond and cause folding/unfolding.
Since I get the expected results, i.e. line numbers in the ruler, when I change from using a VerticalRuler to a LineNumberRuler while leaving everything else the same, I think my problem is specific to the implementation of the relationship among the ProjectionViewer, the VerticalRuler, and the Annotations.
My exact question is whether anyone has gotten this to work in a stand-alone code and, if so, how?