I am wondering..
Is it possible to take advantage of the new C++ syntax, new COM generation, new C++ .NET interop functionality without using WinRT?
I.e. I'd like to write a normal WPF desktop application.
I would like to write some part of it in C++.
I'd like to bypass the previous (and slow & clumsy) interop technology and, if possible, use the new interop one, which will make supereasy and efficient to share my code between C++ / C# without reverting to C++ CLI.
I.e. do I neeed to use C++ CLI / Managed C++, or could I use this new C++ extension with .NET 4.5 WPF desktop app?
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
My programs never have bugs, they just develop random features.
I was surprised to see that with the Visual Studio 2012 RC release they have added Windows Vista support for .NET Framework 4.5.
Has anyone seen any indication that they plan to add Windows XP support in the future?
I do not mean if Microsoft will continue to support the Operating System. My question is whether or not it will be possible to install and use .NET framework 4.5 on Windows XP. Currently it is not listed as being supported.
It may work, but be unsupported as they are trying their best to kill XP off ASAP
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
My point is that a few weeks ago, this article did not have Windows Vista in the list of supported client Operating Systems. That was added with the latest Release Candidate.
I would like to see XP supported once they come out with the final product.
Please I would like to ask, is there any class provided in vb.net with which one can work with system hardware like the sound, webcam, and other system resources and also external devices being connected, easily. Please if there is I would like for someone to point it out to me.
Below is the code that is actually closing the whole application when clicked on Yes.
But,I want to close the current form and open the new form when the user clicks on X with red mark i.e. close on the form.The code I wrote is :
<pre lang="vb">Private Sub form1_FormClosing(ByVal sender AsObject, ByVal e As System.Windows.Forms.FormClosingEventArgs) HandlesMe.FormClosing
Dim response As MsgBoxResult
response = MsgBox("Do you want to close?", MsgBoxStyle.Question + MsgBoxStyle.YesNo, "confirm")
If response = MsgBoxResult.Yes ThenMe.Dispose()
ElseIf response = MsgBoxResult.No Then
e.Cancel = TrueEndIfEndIf</pre>
I am a in disbelief.
I was experimenting with strongly signed libraries lately and found a couple of surprising things.
I create a program and sign it using a strong name key file:
My first surprise was that if I edit the executable file with a binary editor I can make it display any other number.
It appears that the signatures are not checked at run-time.
I then pushed it a bit further.
I can push the original assembly to the GAC but not the modified version.
As it returns : "Failure adding assembly to the cache: Strong name signature could not be verified."
This is expected and I felt a bit better about it.
...Until I tried to copy the modified assembly directly into the assembly cache folders.
If you look at older publications such as this http://msdn.microsoft.com/en-us/magazine/cc163583.aspx[^] from 2006 you would come to the conclusion that strong naming signing an assembly would give some measure of tamper proofing. So it does come as a bit of a suprise to find that you can fire up a binary editor, change some data and it will still load.
It turns out that load time checks for applications operating in a Full Trust environment were disabled by default when .NET3.5 SP1 was released, a change that affected the behaviour of .NET2.0 as well. This Strong-Name Bypass feature can be enabled or disabled on a system wide basis via a registry setting or a per application basis with an entry in the app.config file.
It's explained in MSDN .NET4 docs[^] although I only found out about this after I had discovered that an edited strong named signed assembly would load without complaint. One would hope that the Authenticode signature mentioned in that reference is protecting the core system assemblies.