We have an application where the main UI is coded in vb6. We also have multiple .net assemblies (winform and class libraries) built in vb.net (VS2015, targeting framework 4.5.2).
Can we utilize the winform dotnetbrowser in a .net assembly that is called via com interop from our vb6 main app?
The licensing articles instruct adding the license to the project as an embedded resourse - would this license be added to the .net assembly as an embedded resource? Or would it need to be added to the main app exe (vb6) as an embedded resource there?
Can we utilize the winform dotnetbrowser in a .net assembly that is called via com interop from our vb6 main app?
Yes, this use-case is possible.
The licensing articles instruct adding the license to the project as an embedded resourse - would this license be added to the .net assembly as an embedded resource? Or would it need to be added to the main app exe (vb6) as an embedded resource there?
There are several ways to provide the licence to DotNetBrowser:
the most common and recommended way is to include the licence into
the application .NET assembly as an Embedded Resource (it is
usually done when performing a build)
the other common way is putting
the licence file into the working directory of the application that
loads and uses DotNetBrowser
at last, you can specify the full path to the
licence file using the DOTNETBROWSER_LICENSE_PATH environment
variable
Related
I have created a VS2013 solution that contains multiple projects. One of those projects is a portable class library targeting .NET 4.5+, Silverlight 5, Windows Store 8+ and Windows Phone 8 and this project contains a reference to an OData service in an accompanying web application.
The portable class library references Microsoft.Data.Services.Client.Portable (among others), added via nuget (WCF Data Services Client).
I have then added the portable class library to a WPF (.NET 4.5) application, a Windows Store application and a Windows Phone application and written some very basic test code to access the service. This works fine in Windows Store and Windows Phone.
The WPF application however will not compile. The errors are...
The type 'System.Data.Services.Client.DataServiceContext' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The type 'System.Data.Services.Client.DataServiceQuery`1' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The thing is, I also added the WCF Data Services Client to the WPF application via nuget, but it does not add a reference to the portable library (packages\Microsoft.Data.Services.Client.5.6.0\lib\portable-net45+sl5+wp8+win8\Microsoft.Data.Services.Client.Portable.dll), instead adding a reference to the full framework 4.0 version (packages\Microsoft.Data.Services.Client.5.6.0\lib\net40\Microsoft.Data.Services.Client.dll) - which in turn is causing the error I am seeing.
Is there something I am doing wrong here or is this an error in the installation package? Note that if I delete the offending reference and add the alternative reference manually then all is well so though I have a work-around I would still like to know if I am the cause of the error.
Looking at the NuGet source code this behaviour seems to be by design.
The WCF Data Services Client contains assemblies for the following frameworks:
.NET Framework, v4.0
.NET Portable, net45, sl5, wp8, win8
Silverlight, v4.0
Installing this NuGet package into a project that targets .NET 4.5 will result in the .NET 4.0 assembly from the NuGet package being referenced. NuGet considers the more specific .NET framework to be a better match for your WPF project which targets .NET 4.5.
There is a comment in the NuGet source code about this when it looks for the best matching assembly in the NuGet package.
// Let's say a package has two framework folders: 'net40' and 'portable-net45+wp8'.
// The package is installed into a net45 project. We want to pick the 'net40' folder, even though
// the 'net45' in portable folder has a matching version with the project's framework.
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 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 have a Silverlight app hosted in an Azure web role ASP project. The ASP project exposes a WCF service.
I would like to have one set of class definitions for the data types. Someone recommended making a third project (class library) and adding a reference to it from the SL and ASP. I started doing this, but the Silverlight project complained that you can only add references to Silverlight projects.
I then made a Silverlight class library and moved the data classes to it. However, I to add some .dll references, like to the Windows Azure storage client. Then the Silverlight class library tells me I can only add references to Silverlight 4-friendly .dlls, of which Windows Azure isn't one. Fantastic.
Is there something I can do to get around this, or am I stuck with a less elegant, redundant solution?
Multi-targeting is your best bet. There is an article explaining this in Visual Studio from Microsoft at:
http://msdn.microsoft.com/en-us/library/ff921092(PandP.20).aspx
Basically, you create both your Silverlight and standard .NET class libraries, each with a different name, and then include the same files into each. Usually the files are actually only in one of the class libraries and then soft linked in the second one.
The key is to ensure that the code in your files is compatible with both runtimes. If there needs to be separate implementation for some of your methods depending on the runtime then you need to separate these with pragmas (i.e. #ifdef SILVERLIGHT...).
If you're only doing data structures, however, there should be no issues as long as Silverlight supports the objects you are using.
See if using linked files as per this answer does the trick for you.
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 :) .