Is there any tool / commercial obfuscator that can obfuscate BAML resources in WPF controls?
If not, its a tough time in terms of IP protection sicne hackers can easily peek into the BAML resource by using BAML to XAML converters.
Herein lies the problem with .NET stuff: Claytons Open Source -- the open source you do when you're not doing open source.
This subject has been visited a bit elsewhere on the web:
Protecting my intellectual property/XAML
Code Protection and Licensing of WPF Applications.
.net obfuscator {smartassembly}
The latter looks promising.
I know it's been a while since you wrote your question, but I wanted to inform you that obfuscation of XAML and BAML code is now possible.
At Creatix we have today released the 1.0 version of CodeFort, an obfuscation tool which is able to obfuscate .NET, WPF and Silverlight assemblies, and even rename identifiers inside of XAML and BAML code. This makes it for the first time ever possible to obfuscate 100% of a WPF or Silverlight Application's types and members.
You can learn more about the obfuscator and download the CodeFort Freeware Edition at:
http://www.codefort.org
Best regards,
Christian
Eazfuscator.NET performs intelligent XAML obfuscation, including careful processing of the most complex binding expressions, etc. You can read more about it here.
Crypto Obfuscator obfuscates XAML (in Silverlight assemblies ) as well as BAML (in WPF assemblies) - it renames class/member references inside the XAML/BAML files. Plus it will strip all comments, newlines and whitespace in these files turning them into garbage to the human eye.
Related
[Disclaimer: I'm a long-time Desktop developer slowly learning Web and Blazor, so might be a noob question] but,
How come, when you try to find best-practice for doing Localization in Blazor you are told from official MS Docs (https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-5.0&pivots=webassembly) and various blogs to do the following:
Add NuGet Package: Microsoft.Extensions.Localization
Register localization "builder.Services.AddLocalization();"
Add your resx Files
Make IStringLocalizer (#inject IStringLocalizer Loc)
And finally use the following in your razor pages: #Loc["Greeting"]
Sure above works, but to a Desktop developer, this feels like a massive step-back in quality and "refactor-safeness" and the new way to use "magic strings" to reference the translations.
I've tested, and the "old way" on a Blazor Page of just:
Adding a MyResource.resx
Let it use the custom tool "PublicResXFileCodeGenerator" to make the .designer file
Simply reference the translation using MyResource.MyTranslationKey;
It works, it is refactor-safe, no need for an injection or NuGet packages... It just works, but despite that, it is not the recommended way... My question is why not? What is the drawback (all the blog and documentation fail to say why the new way is better)
I think there are a number of disadvantages using PublicResXFileCodeGenerator, which may have led to the current recommendations on how to support i18n-capabilities in [blazor-]apps.
Note that this is just a list of reasons I personally came up with finding possible causes which may have led to the current recommendations:
A: Visual Studio exclusivness
The way how PublicResXFileCodeGenerator generates files seem to be VisualStudio exclusive. Today´s teams tend to use a variety of IDEs / editor to build software, (f.e. VS, VSCode, Rider, WebStorm, etc.).
At least from my perception over the last couple of years
using IStringLocalizer works for all editors, even notepad or vim.
B: no default fallback
With the recommended way of accessing a translation, there will always be a useful fallback which is provided in markup. That is not the case when using the generated types to access translation-units.
C: no builtin-support for interpolation
Using IStringLocalizer, there is a built-in, lightweight and formalized way for utilizing interpolated strings. It even encourages using such strings in favor of manually building together such values, which is considered bad-practice when translating software.
DO:
#inject IStringLocalizer<DemoPage> L
<h1>#L["Greetings, {0}", userName]</h1> <!--Greetings, Arthur-->
#code {
string userName = "Arthur";
}
DON´T:
<h1>#DemoPageRessources.Greeting #userName</h1> <!--Greetings Arthur-->
#code {
string userName = "Arthur";
}
this dictates the order of strings, which might be OK for one language, but not for another. Achieving this with the generated type is a bit more verbose, and even may lead to runtime-exceptions, when there is no actual translation, i guess.
Is there any migration analysers available for MonoTouch ?
I have seen one for Mono, but not for MonoTouch.
Short answer: No, there is none at the moment.
Long answer
The situation is a bit different from Mono. In general you test a complete and compiled (against a specific version of the framework) .NET application with MoMA, to get a report of what pieces are missing (or incomplete) in Mono that could affect the execution of your application on other platforms (e.g. OSX and Linux).
Testing a complete applications for MonoTouch would reports tons of issues - since the UI toolkit is totally different. E.g. anything about System.Windows.Forms, WPF... would always missing.
However if your assemblies are already split into (something like) an MVC design it would be possible to test some (the non-UI parts) of them against definitions based on the MonoTouch base class library.
Finally if someone has an immediate need (or looking for a nice project) MoMA is available as open source and the evaluation versions of MonoTouch contains all the assemblies needed to build the definitions files. A bit of extra filtering could make this into a very nice tool.
Alternative
You can see a list of the assemblies that are part of MonoTouch and some platform restrictions (compared to .NET) you should be aware.
I'm wanting to build an ActiveX control to upload files from a user's machine on a web page.
Where can I fnd a good example or tutorial for this - I guess C++ would be my preferred language, but VB would be OK too.
ActiveX is a dead technology. I can't think of a good reason to use it instead of Silverlight.
I've actually written one in Silverlight myself. You can see it on my website if you want to take a look.
As perhaps you know already, most probably the next version of Delphi will be cross-platform. Also, here are some polls on the matter.
While writing a cross-compiler isn't a thing which interests us very much now, porting a library which was/is Windows-tied to multiple platforms, certainly does.
You can think, for example at VCL (Delphi's standard library). While it was designed for Windows only, it has value in it, and, of course, there are huge codebases which depend on it.
The question is:
Which would be the best approach to made an application / library cross-platform aware ensuring a smooth conversion / upgrade path (as much as possible of course)?
I stress it again, we are not interested which is the best way to do cross-platform development only (there were questions on this theme). We are interested also in yet another requirement: The old code base / installations management.
PS: Experiences and/or methodologies from similar situations with other languages (eg. C/C++) which are regarded as standard practices are welcomed.
Thanks in advance.
Visual component developer's perspective:
Add levels of functionality to your code, so as to be able to add another platform without changing the "Core" of the component.
The compiler hopefully will have a platform switch. (Preferable more than one, working in conjunction with each other. ex. Windows/ARM, Windows/386, OSX/Cacao/386, Linux/Gnome/386).
The Layout structure might look something like this.
ComponentJ.pas
Linux\ComponentJ.pas
Linux\Gnome\ComponentJ.pas
Linux\KDE\ComponentJ.pas
OSX\ComponentJ.pas
386\ComponentJ.pas
ARM\ComponentJ.pas
As an Application Developer:
I'll start by moving all WIN API calls in my code into a group of libraries in a Windows directory as to be able to IFDEF it at library level and translate it into another platform I'd like to support as soon as the compiler becomes available, but only as I come across them.)
This will also add the possibility to add adapters easier for the new platforms.
It in any case is good practice to remove possible dependencies into a central place.
IMHO you can't build a xplatform Delphi and ensure a smooth transition for current VCL applications. It won't work. VCL was (luckily, because it allowed for great applications) designed with Windows in mind, and trying to design a compatible library working on a different platform would just mean longer development cycles and lots of compromises. The outcome will be a library noone would wish to use. Look at what happened to VCL.NET: it was the wrong choice. And it was working on the same OS!
We know that targeting non-Windows platform with native applications needs a native GUI library. We don't care about creating a GUI from scratch, for our application it's the way to go, we don't need Windows GUIs with all their standards under a different OS using different standards - we need to be able to code a fully native GUI for the target OS.
Other applications may survive a GUI porting, but in the long run you don't get a real xplatform tool - you get a tool that may compile for other platforms but brings one platform paradigms to others - and it will also be not welcome by "native" developers on other platforms. If you're a Linux or Mac developer, why should you learn how to work with a library that carries its Windows inheritance to your platform? You'd find it a pain in the ass. If Embarcadero wants to sell XDelphi outside actual developers base, it has to offer much more than a new CLX.
I will pull from some ancient experience in making a code base cross compilable between windows and dos (Delphi 1/Turbo Pascal 7). The rule of thumb was to separate code into multiple units. Try to code WITHOUT using windows, messages or any visual components. If you find you need to make a call to one of these, then place that call in another unit and write a proxy (abstract class that you descend from works well) to dispatch the calls through. When a cross compatible version is released, all that you should have to do is code the other side of the proxy for the new target.
If you're designing a form based system, then try to stick with as many of the standard components as possible. NEVER implement any "business" rules directly in an event, instead place them in another unit and call into the other unit to perform the logic.
Now, there will definitely be changes required to get your final project cross compatible, but by following these simple patterns you should be able to greatly reduce the amount of work it will take.
Experience so far has shown that the best way to get a Delphi app compatible with future versions is to stick to pure Delphi components, and use nothing third party. Such an app will probably suck, but that's how it seems to me. I use lots of third party components, and the apps are great and successful. But the chances of them moving to this future too are not certain, and that may cause problems with such changes, but I'd rather have a great app now and have the problem than have a poor app now and not need to worry about it.
Compromises should not be done too much to make VCL compatible with Linux and Mac. Windows is VCL's root. I'll prefer a new and very clean GUI framework, even though without any backward compatibility. Make VCL fatter and fatter isn't a good idea!
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
Well, look at freepascal and lazarus
I don't get it. All .NET looks the same to me providing we don't use any third party.
Delphi using standard control is already fully functional but your app would look
like thousands of others.
I think Embar should go for PDA, IPhone, Andriod as Windows desktop already eat about
98% of the market.
Mac is expensive and Linux is no cost at all. No use to go for Mac and Linux. Not worth
the investment.
Well, aside the things said - thanks all - I do think that there we need some additional things:
we need tooling to do the necessary conversions
we need tooling to help us in programming against a (some form of) MVC pattern
Simply pick the latest 4.6 QT and add good integration betwen the Pascal and the QT library.
They have done it before (in the Kylix times). The QT is such powerfull these days.
I believe that QT is even better then VCL and at least 10 times more frequently updated and fixed.
So the plan is simple:
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
and you will have a first-class natively looking applications on all platforms.
My opinion:
Make cross platform compiler (OS x/Linux/ embedded solutions?/ symbian?). Maybe add ability to compile/convert pascal code into portable c/c++ code to build then on embedded platforms.
RTL have to be separated into cross-platform layer and native layer (as for JCL).
Add new core components for cross-platform compatibility and native components for each supported platform (QT for ex)
Add translation utilities to create/convert between platform's components, for ex: to convert pure windows form into mac os x cocoa's form.
All windows hierarchy of components have to be only upgraded to support x64 with maximum backward compatibility. All cross-platform component have to be in parallel hierarchy.
Next version of cross platform solution can be refactored and can include migration/convertion utility. Due to minimum codebase of cross-platform solutions, hierarchy and classes for cross platform can be heavily changed from version to version to achieve best architecture.
sorry for my English - not a native language (Russian is)!
Make C/C++/Delphi compilers that targets OSX/Linux
Make C/C++ compiler that can be Boosted
Write new VCL-Presentation Foundation (VGScene/WPF alike)
it should not be backward compatibile! Delphi IDE should be
written with such VCL-PF
Component Library should stay as it is (but with improved Data-Binding)
Only provide VCL 64-bit for Win64
Is this a problem?
Are there any support tools like coderush or resharper for F#?
Preview version of FSharpRefactor released in Visual Studio Gallery.
http://visualstudiogallery.msdn.microsoft.com/339cbae9-911d-4f99-9033-3c3564676f45
http://www.youtube.com/watch?v=T6-YjUULNCA/
F# Refactor open source project on CodePlex (Apache license).
Take a look at the open-source Visual F# Power Tools project. They've got a rename refactoring, some code generation stuff (eg. record stub generation), graying out of unused declarations, as well as some other things. They're moving pretty fast at the moment, with lots of new features getting added all the time.
There's an effort to support F# in ReSharper via an external plug-in (itself written in F#). You can find preliminary info here.
FSharpRefactor 0.1 (Preview version) Released on the Visual Studio Gallery.
http://visualstudiogallery.msdn.microsoft.com/339cbae9-911d-4f99-9033-3c3564676f45?SRC=Home
Not yet, as far as I know. I was also looking for something similar to no success. I suspect as soon as F# hits VS2010 as its integral part, or even a bit earlier, such tools will eventually emerge.
As far as ReSharper is concerned, you may want to drop JetBrains a quick email, it would be interesting to know whether these guys have any plans regarding F#.
Since the push in f# is towards light mode the reformatting possible is likely to be both limited, and hard to implement.
Normally reformatting takes the structural information and uses that to create the textual position. In the case of #light the textual position (of indenting at least) is the structure. As such any reformatting would be at best to sort inter symbol spacing, hardly onerous to do yourself.
I would therefore not expect a commercial product for it at least until the 'proper' integration with the IDE (I do not consider the current CTP proper in this regard since several outstanding bugs with it exist which will not be fixed in 2008)
CodeRush is working in F# editor. At least some code assistance and code templates. But code templates are not defined yet (you have to create your own).