Is it possible to embed all .net dependencies to the final exe file because I want it to run on every windows machine even without preinstalled .net?
Use ClickOnce, and setup the dependencies, so that it installs the prerequisited .Net framework.
ClickOnce is good for dealing with the deployment of your application.
To embed all .net dependencies you can use ILMerge or, even better, this approach by Jeffrey Richter (which is recommended from inside the ILMerge website too).
I am not sure about the lagality of this but you can possibly use reflection to get the code from the parts of the .NET framework which you are using and re-create them as your own classes. Then use those classes when building your application.
Edit: I am not sure that you can reflect the entire .net framework though.
Related
Is there any way I can invoke White UI Automation tool from Java?
I already have a Java framework with me and now I need to handle some Silverlight application (which is legacy code and the developer has not made it scriptable). I don't want to maintain a separate workspace/technology for this. Is there any way I can call White UI or the underlying Windows UI Automation from within my Java code?
Perhaps IKVM would work? I haven't used it before, but it looks like it allows you to run Java code that can directly access .NET assemblies.
So, sounds like it might be a way to use both White and your Java test framework at the same time.
There's an interesting tutorial here (see the section Developing a .NET application in Java):
http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=Tutorial
And the main IKVM website is at ikvm.net
I've been trying to sort this out for some time now..
I have a few .NET libraries that work as an SDK to an external application. I need to use that SDK both from a WPF Class Library and a Silverlight Class Library. I've been reading a lot of solutions including:
Portable Class Libraries - When I try to add the SDK libraries to the project, it complains that those libraries reference .NET 2.0 libraries and it is incompatible.
WCF RIA - I may be doing this wrong, but everywhere I turn, one step of the process is to create an Entity with the EF. Now, I don't want to access a DB, just those libraries.
But so far, no luck. Any ideas you would like to share?
As far as I know, it may not work if the old .NET 2.0 binaries have references to COM or system libraries. That could relate to your DB implementation. I have had this problem in a project in a previous job. We solved this by creating a WCF service as a in-between solution. That was WCF and not WCF RIA.
If the .NET 2.0 code is really old, you should check if it must be compiled as x86 and hosted as a 32-bits application on AppPool of the site that hosts the WCF service in the IIS.
But this is tricky business, and it all depends on the complexity of the old .NET 2.0 library file and its references.
I have started to use WIX to deploy a WPF application. I have created the .wxs file with the desired interface features etc...
My questions is how to distribute the required .Net files that support my WPF executable? Not the .net framework or sql server express, but the dependencies needed to run my executable.
Should the process include building a msi with VS Installer, then including that msi into my WIX script and running that inside of my WIX msi?
Or, what is the correct process for distributing a WPF executable with WIX?
I don't think your question pertains to WiX or WPF at all. What you need to ensure is that you package up the necessary dependencies along with your installer, whatever they may be. Referencing your dependency files in your installer script should be sufficient.
Here's the process that I follow for any application.
1) Start with a clean VM that represents the least common denominator of a machine I want to target. Let's say WinXP SP2 32bit.
2) Deploy my application by hand and record all of the steps in a word document. Then try those steps on other OS's to make sure you didn't miss anything.
3) Take each of the steps in my document and implement them in WxS. Keep in mind that Windows Installer and Windows Installer XML is a declarative programming language not an imperative programming language. You don't tell it to xcopy files from dir a to dir b, you describe the directory structure and the installer takes care of it.
BTW, of the things you mentioned, your asking for help with what I consider the simple stuff and excluding the harder more complicated stuff.
As an alternative way, you might see also this post Embedding dlls in a compiled executable to embed all the dll needed (like the interop ones for example) using Costura.Fody. Using WIX there is no more need to add any dependent dll as components in the .wsx file.
I am trying to integrate IronPython in my Silverlight application but am unable to do so. After downloading the binaries, every time I try to add the dlls as references in my VS2010 solution all I get is an error about them not being compiled for Silverlight. I have even tried downloading the source distribution, but cannot set the various projects making up the solution to build against Silverlight (the only choices I have are different versions of the .net framework).
As the IronPython website explicitly states Silverlight compatibility, why is it not working? Is there any easier way of getting scripting capabilities in my Silverlight app?
You have to use binaries from IronPython-2.6.1\Silverlight\bin folder in Silverlight.
I was wondering if anyone has any advice for obfuscating a DSL?
Background - We have created a DSL which we will putting into the Visual Studio Gallery as a VSIX file.
We already use dotfuscator for our obfuscation on other projects but I would like to know if there are any best practices or issues when packaging a DSL for deployment as a VSIX
Disclaimer: I am a developer at PreEmptive Solutions, the makers of Dotfuscator.
As long as your DSL assemblies are managed code you can use Dotfuscator on them. The 4.6.1005 release of Dotfuscator Professional provides support for .NET 4.0 Beta 2 assemblies. As long as your support contract is current, PreEmptive will provide support in the event you run into any issues.
The only external process you will need to implement is one to update your VSIX file either manually or via a script that will replace the unobfuscated assemblies in the original VSIX with the obfuscated ones output by Dotfuscator. See http://blogs.msdn.com/quanto/archive/2009/05/26/what-is-a-vsix.aspx for details on the structure of a VSIX and how to work with them.
While the 4.6.1005 version of Dotfuscator has been significantly updated to accept and emit XAP files, ClickOnce manifests and directories we have not yet implemented the ability for Dotfuscator to natively process VSIX assemblies. I have put this enhancement on our request list :) .