Load a behavior extension from MEF plugin - wcf

I am really hoping someone would have some input for my problem.
MyApplication.exe
|
|
|-Plugins (Folder)
|
|- Plugin1 (Folder)
| |
| |- MyPluginAssembly1.dll
|- MyPluginAssembly.AppConfig
|
|- Plugin2 (Folder)
|
|- MyPluginAssembly1.dll
|- Assembly1.dll
|- Assembly2.dll
The plugin I am trying to access is Plugin1 with a config file.
The Plugin connects to some WCF services for another application which is not related to the MainApplication.
The config file has the following
<extensions>
<behaviorExtensions>
<add name="Version" type="SomeApplicaiton.MyClientBehaviorExtensionElement, Some-Application.App, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>
</extensions>
Plugin1 which has some wcf services it needs to connect inorder to load. Problem is that it will not work if the behavior extension assemblies are located in the plugins folder. The .exe which is loading the plugin cannot load the assemblies unless they are registered or resides within the exe folder.
On my development this works perfectly. But when the plugin is accessed, it gives me an error that the Version, MyClientBehaviorExtensionElement behavior extension cannot be loaded.
I have no control over the exe. Is there a way I can load this extension instead of putting the DLL in the exe folder

AppDomain.CurrentDomain.AssemblyResolve += (sndr, resolveEventArgs) =>
{
return Assembly.LoadFile(....._
}

Related

Using SqlClient in an MSBuild Task targeting netcoreapp2.1

I've written an MSBuild Task like this one, but mine has a reference to System.Data.SqlClient.
So I use dotnet publish to target the specific framework netcoreapp2.0 to get the dependencies in the bin dir.
The problem with this is when I run the task through an msbuild script I get: error : System.Data.SqlClient is not supported on this platform.
The build engine: Microsoft (R) Build Engine version 15.7.177.53362 for .NET Core.
Here is the complete (task & test) project
The csproj:
<Project DefaultTargets="Build">
<UsingTask TaskName="TestTasks.TestSqlClient" AssemblyFile=".\Task\bin\Debug\netcoreapp2.0\publish\TestTask.dll" />
<Target Name="Build">
<TestSqlClient />
</Target>
</Project>
list of files and dirs under bin\netcoreapp2.0\publish:
| Microsoft.Build.Framework.dll
| Microsoft.Build.Utilities.Core.dll
| System.Data.SqlClient.dll
| System.Text.Encoding.CodePages.dll
| TestTask.deps.json
| TestTask.dll
| TestTask.pdb
|
\---runtimes
+---unix
| \---lib
| \---netstandard2.0
| System.Data.SqlClient.dll
|
+---win
| \---lib
| +---netcoreapp2.0
| | System.Text.Encoding.CodePages.dll
| |
| \---netstandard2.0
| System.Data.SqlClient.dll
|
+---win-arm64
| \---native
| sni.dll
|
+---win-x64
| \---native
| sni.dll
|
\---win-x86
\---native
sni.dll
It appears you have run into https://github.com/Microsoft/msbuild/issues/1887. One of the current limitations of using dependencies from MSBuild tasks is that MSBuild will not load native dependencies. As you can see in your output, there is a “runtimes” folder which contains sni.dll for x86, x64, and more. The only way to workaround this on .NET Core is to manually resolve native dependencies youself using assembly load context. This is very difficult to do right and I don’t recommend it. See https://natemcmaster.com/blog/2017/11/11/msbuild-task-with-dependencies/ for more details.
A simpler workaround is to implement your tool as a console tool. Then use a target and the Exec task, or a customized implementation of ToolTask, to run your console tool during build. This is how the C# compiler itself works, and I have described this approach in more detail here: https://natemcmaster.com/blog/2017/11/11/build-tools-in-nuget/. Also, see https://github.com/natemcmaster/Yarn.MSBuild for a real-world example.

Build output of MVC6 app. How does it works now?

I am checking out the default MVC 6 application and published the build on local file system. This how it looks like when i check Compile source files to nuget pacakges
I can see 3 main folders: approot, logs & wwwroot
Inside approot:
I can see that my WebApplication1 is now as a nuget package.
What is ef file in approot>Packages>WebApplicaton1>1.0.0>app ?
ef files are in approot too along with 2 web files. What are they ?
Inside wwwroot: It has all my static resources like css and js.
How does all this fall in place when we deploy the application in IIS or azure ?
The ef and web files in the published output correspond to the ef and web commands that you have defined in your project.json file. You could define more commands in your project.json file and all of them would show up here.
Starting with beta-8 version, ASP.NET 5 uses a module in IIS called HttpPlatformHandler which forwards http requests to a external process...in our case it would be the dnx.exe process. For example, you can take a look at the following web.config file under wwwroot which shows the module registration and also the path to execute the external process...as you can see here web.cmd is being used.
<configuration>
<system.webServer>
<handlers>
<add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
</handlers>
<httpPlatform processPath="%home%\site\approot\web.cmd" arguments="" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout.log"></httpPlatform>
</system.webServer>
</configuration>
This kind of design is suitable for non-Windows scenarios too...for example, you could use your app with the nginx reverse proxy too
More deeper details can be found in the following link:
Change to IIS hosting model

Eclipse RAP: How to access deployed application

I created a helloworld eclipse RAP project and run it eclipse itself.It is working fine.
After that I exported the RAP project to war file by using the eclipse war product configuration.
It created the war file.I deployed the war file in tomcat. After that when I try to access
the war deployed helloworld application, I am getting status 404 error.
http://127.0.0.1:8080/helloworld
I searched in internet and checked for troubleshooting and they mentioned to check in web.xml
all the entries are available or not. I confirmed it is available. Also I checked application structure.
It is fine as it is suggested. Could any one help me how to access the deployed application in tomcat?
Or is there any other server I can use in order to make it work quickly?
I suppose that the war file is named helloworld.war and http://127.0.0.1:8080/helloworld is the URL of your application.
If your entrypoint is not registered at the root path, you have to add the entrypoint name to the URL, e.g. http://127.0.0.1:8080/helloworld/entrypoint.
Alternatively, you can register the application at the root path in your ApplicationConfiguration:
application.addEntryPoint("/", YourEntryPoint.class, properties);
Then you should be able to access it at http://127.0.0.1:8080/helloworld.
Update:
If you use extension points, configure the path in your entrypoint extension, for example:
<extension
point="org.eclipse.rap.ui.entrypoint">
<entrypoint
class="example.MyEntrypoint"
path="/" />
</extension>

Mule Development structure

I am trying to develop one mule application using eclipse plugin . Mule version is 3.1 . Which will be the base directory of my mule project (is it Mule_Home/apps folder) ?
Or I need to develop it outside of Mule bundle and place corresponding jar file under Mule_Home/lib/user directory ? If so then again need to place mule-config file under apps folder ?
Thank You
Here's the MuleStudio generated structure:
/lib
/mappings
/mule-project.xml
/src/main/api
/src/main/app
/src/main/java
/src/main/resources
/src/test
/src/test/resources
Your flows go in /src/main/app. Here's a sample pom file to build based on the structure above https://gist.github.com/tjsnell/8147194
You can refer below link for the format.
https://docs.mulesoft.com/mule-user-guide/v/3.7/application-format
Mule Application Format
The deployment unit of a Mule application encapsulates everything an >application needs to function, such as libraries, custom code, configuration, >deployment descriptor and any environment properties accompanying the >application. It exists in one of two formats:
.zip file (a regular archive with a 'zip' extension)
unpacked version of the same .zip file (exploded app)
\- classes // application-specific expanded resources (e.g. logging configuration files, properties, etc
|- lib // application-specific jars
|- plugins // application plugins files
\- lib // application shared plugin jars (FROM 3.7 and +)
|- mule-config.xml // Main Mule configuration file, also monitored for changes
|- mule-deploy.properties // Application deployment descriptor (optional)
|- mule-app.properties // custom properties to be added to the registry instance used by the application (optional)
|- *.grf files // produced by DataMapper to plot its data mapping
Mule supports the deployment of both packaged (zipped) and exploded (unzipped) applications.
You can share libraries between applications via the application deployment descriptor attribute.
It is better to know Mule Application Format
Tracy Snell is right. I use Anypoint Studio and the Mule source folder on the build path is src/main/app. That's where your mule-app.properties, mule.deploy.properties, and your project_name.xml go.
Mule-project.xml is the main xml to define your flow and you can add more xml's flows to your main xml if required and mule-app.properties and mule-deploy.properties will be loaded in the flow by default to acess the tokens.
You have to develop your new application in /src/main/app folder.
if you want to include any resources like static
properties that have to be developed in /src/main/resources folder.
if you want to include any java resources that has to be in /src/main/java.

NUnit not reading the configuration file

I have written a NUnit tests for a .NET application. When I run the NUnit, it does not read the connection string values from the configuration file. I tried many solutions with out success, like
Adding <assembly name>.dll.config file in the path where NUnit loads the DLL file.
Adding the configuration settings in NUnit.exe.config/NUnit.gui.config
I wasn't able to read the configuration setting even when run in VSNunit. Is there a solution?
I've assumed
Assembly being tested: SomeNameSpace.MyClassLib
NUnit assembly with unit tests: SomeNameSpace.MyClassLib.Test
Try this:
Make sure that you have also copied your app.config to your NUnit Test DLL class library (i.e. project SomeNameSpace.MyClassLib.Test) as well.
Build your NUnit Project (e.g. to SomeNameSpace.MyClassLib/bin/debug) and make sure that following are in the bin\debug (or release) directory
the assembly to be tested,
the NUnit test DLL and
the configuration (SomeNameSpace.MyClassLib.Test.config)
any other assemblies needed by your DLL file being tested.
Edit your NUnit Project in the XML view of the NUnit GUI Project editor (menu Project → Edit, or just edit it in Notepad), and make sure that the test assembly (MyClassLib.Test.dll) and the configuration file names are relative to your appbase
For example,
<NUnitProject>
<Settings activeconfig="Debug" processModel="Default"
domainUsage="Default"
appbase="C:\Temp\MyProject\MyClassLib.Test" />
<Config name="Debug" binpathtype="Auto"
configfile="bin\Debug\MyClassLib.Test.dll.config">
<assembly path="bin\Debug\MyClassLib.Test.dll" />
</Config>
<Config name="Release" binpathtype="Auto" />
</NUnitProject>
Add an app.config file to the test project and add your configurations in there.
You then have to tell NUnit what configuration to use as by default it will not pick up the app.config file.
More information on how to set this up with screenshot.
I was stuck on a similar issue for a while. We also need to look at how you are loading the assemblies, based on that the naming of configuration file changes (unless you are using an explicit configuration file from settings). As mentioned here:
http://www.nunit.org/index.php?p=configFiles&r=2.2.10
If a single assembly is being loaded, then the configuration file is given the name of the assembly file with the config extension. For example, the configuration file used to run nunit.tests.dll must be named nunit.tests.dll.config and located in the same directory as the DLL file.
If an NUnit project is being loaded, the configuration file uses the name of the project file with the extension changed to configuration. For example, the project AllTests.nunit would require a configuration file named AllTests.config, located in the same directory as AllTests.nunit. The same rule is followed when loading Visual Studio projects or solutions.