Hi guys/gals, hoping someone has run into this before...

We are trying to upgrade to SLX 8.0, however, we have created many extensive .net extensions in the past 5 years on older versions.

We are compling our extensions in .NET 4.0 now, and when we try to deploy, we are getting an error through the architect:

mixed mode assembly is built against version 'v1.1.4322' and cannot be loaded in version 4.0 without additional configuration information

Our .net extensions depend on other third party tools that were compiled in earlier versions - so the .dll we are compiling is a "mixed mode" assembly. Google searches indicate that we just have to put something in our app.config file so the application knows which version to use - however, we are not creating an application - we are creating a .dll to import into the application architect.

Has anyone run into such an issue, and are there any solutions?

thanks very much!

We just figured out how to get the plugin deployed. We couldn't go through the Architect. We had to use the SLXNetExtensions.exe outside of architect.

Then I just created a config file for that "SLXNetExtensions.exe.config", and in that config file, we are able to put the following known fix for running a mixed mode assembly with 4.0:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

The important part of that config section is the "useLegacyV2RuntimeActivationPolicy" = true

Hope this helps someone!

Brian,

Can you give a little more clarity?  Are you saying that you created an app.config file for SLXNetExtensions.exe, or for your .NETExtension?  I've got the same issue in that I'm trying to use the Crystal Runtime (FW 2.0) in a .NET Extension (FW 4.0).  Like you, I found the documentation around the LegacyActivitation, but I can't get it to work.  I've tried putting the app.config within my assembly but it doesn't work.  I also just found your post and tried creating the SLXNetExtensions.exe.config file to no avail...

yep, so the way I did it was this:

On the machine you are tyring to deploy from, go to your SLX install folder

(C:\program files\saleslogix) and locate the SLXNetExtensions.exe, and create a new file called SLXNetExtensions.exe.config - like you mentioned.

Add the text as mentioned above, and then run the SLXNetExtensions.exe

From here, you should be able to find the .dll that you want to deploy, and the net extensions deployment tool should add it.

couple things:

1. I am using version 8.0 to deploy

2. what is the error you are getting? Is the net extensions tool still throwing that same mixed mode error when you are running it "stand alone" outside of the architect? Basically, that config file is telling the deployment tool that it is ok to load a mixed mode .dll file

3. We found that even after deploying the .dll file(s) that was just half the battle. When the application actually tries to run the code, it basically will run into the same mixed mode issue. We found some code that will allow you to set that legacy flag at runtime - http://reedcopsey.com/2011/09/15/setting-uselegacyv2runtimeactivationpolicy-at-runtime/

Hope that helps you!

Brian

Brian,

Bingo.  The key is setting the V2 CLR at runtime as per your link above.  You don't need the app.config in the .NET Extension (I believe that this is simply ignored since the calling application (SLX) is FW 4.0).  I don't believe that the app.config in SLXNetExtensions.exe does anything either.  I got it all working using only the runtime.

Thanks a lot for posting the link.  I've wasted a ton of time on this, so I'm glad to have a resolution.

Glad I finally help someone else on this forum!

The original issue we had was that we couldn't even deploy the .net extensions through the way that we normally do it - through Architect -> Manage -> .net extensions

So we tried to use the SLXNetExtensions.exe to deploy, but we were still getting the "mixed mode" error, so setting the values in the SLXNetExtensions.exe.config (a file that we created) allowed us to get past that issue, and finally deploy the .dlls

Anyways, glad you got it solved!

Brian