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.
Related
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.
I maintain an old vb.net project that I didn't make and I was wondering if there's an easy way to determine which parts of the software is still used today by the staff where I work.
I would like to log all function calls without having to edit each one of them if possible.
The project has 27 forms and 6 modules.
Any ideas?
Thanks!
There is no way to 100% determine everything that is used by the system. Vb.Net supports dynamic invocation of methods / properties. Hence you can't even do tricks like delete some code and see if it recompiles. Even if it compiles it could be invoked dynamically.
One way to get a sense of what code is used is to profile the application. Start up the profiler, run the app and go through all of the ways in which the app is used. The resulting profile should give you a good sense of what parts are used. It's very possible though this approach will miss code though
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 want to implement a Webbrowser in my vb.net (2008)-project, however, I don't like the inbuilt IE.
I also remembered that is was kind of easy to implement a mozilla-tool like the gecko-webbrowser in the past...
It was kinf of more complicated than I remember, as I had to dwnload xulrunner and Skybound.Gecko.dll which both probably have to be included in any publishing of the finished project... I also defined x86 as target CPU and made all the needed steps to use a GeckoWebBrowser within my Application. I also called Skybound.Gecko.Xpcom.Initialize(My.Application.Info.DirectoryPath & "/xulrunner") before compiling it.
However, when I try GeckoWebBrowser1.navigate("http://...") (The element was inserted with this name per designer) the IDE tells me that an objectreference is not set to a objectinstance as if GeckoWebBrowser1 isn't defined yet... but the GeckoWebBrowser1.Created attribute is giving back true.
Does anybody know why it isn't working yet?
I have the same error in my solution. Try to use GeckoFX assembly. I use 15 version dll and error fix.
https://bitbucket.org/geckofx/geckofx-16.0/downloads
I'm currently trying to write a program in VB.NET which fluidly changes the DWM window colorization colors in Windows 7.
I first tried to edit Registry values directly, but I had to restart the UXSMS service. This solution was unsatisfying, because of the toggle of the taskbar.
I'm now searching for a function in a DLL such as user32.dll or themecpl.dll which can reproduce the behaviour of control panel when setting the window color.
I'm now on IDA, searching for the adquate function (CColorCplPage::SetDwmColorizationColor seems good!). If anyone has one, please share it!
(If anyone need screens or code, please ask. Sorry for my poor English.)
Your first attempt failed because manually editing the Registry is never the correct way to change system settings. As you found out, lots of Windows components (and other applications!) read those configuration values once and cache them, preventing your changes from being propagated. Another problem (and you'd be surprised how often I see this) is applications that attempt to muck around in the Registry generally end up corrupting things.
Instead, you should call the documented API to change the settings. There's almost always a documented way of doing this, and if there isn't, well then you shouldn't be doing it.
This appears to be one of those cases. There's a documented DwmGetColorizationColor function, but there's no corresponding DwmSetColorizationColor function, as one might expect.
The reason is that the user is supposed to be the only one who can change their colorization settings, not other applications. You might promise not to abuse this, and to only make such changes at the user's explicit request, but not all applications can be trusted to do this. Lots of people would use it maliciously, so these functions have not been documented and exposed.
But as usual, if you press on, you can usually find an undocumented way of doing things. The problem with using undocumented functions is that there's no guarantee they'll work or continue to work. They've been intentionally left undocumented because they're liable to change on new versions of Windows. You should only use them at your own risk.
In this case, if you use a program like DumpBin to obtain a list of all the exported functions from the DWM DLL (dwmapi.dll), you'll see a number of undocumented exported functions.
The ones you're interested in are DwmGetColorizationParameters and DwmSetColorizationParameters. Both of these functions take a COLORIZATIONPARAMS structure as an argument that contains the values they need.
So, you need to reverse engineer these functions and obtain the appropriate definitions. Then, you can call the DwmGetColorizationParameters function, passing in a COLORIZATIONPARAMS structure to obtain the current configuration settings; modify the member of the structure that contains the current colorization color; and then pass that modified version of the structure to the DwmSetColorizationParameters function.
Did I mention that I don't recommend doing this?