11/26/2024 2:24:38 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss general external development topic (related or not to SalesLogix development). View the code of conduct for posting guidelines.
|
|
|
|
.NET Framework compatibility
Posted: 12 Mar 06 9:33 AM
|
asthma rescue inhaler brands rescue inhaler dosage
Was anyone else aware of this issue? Did SalesLogix document this anyware?
If not, I am here to let you all know that this is an issue that causes some very strange behavior in SLX 6.2.3.
Don Poggio
MCSD, SLXD6 |
|
|
|
Re: .NET Framework compatibility
Posted: 12 Mar 06 9:44 AM
|
Hi Don,
What exactly are the problems you were seeing? I have .NET 1.1 and .NET 2.0 installed on *almost all* of my workstations and no issues at all with SalesLogix 6.2.3.
Any specifics on the problems you're seeing?
-Ryan |
|
|
|
Re: .NET Framework compatibility
Posted: 12 Mar 06 11:27 AM
|
Ryan,
We were seeing lots of generic errors related to opening a number of our custom plugins. One thing about our custom plug-ins is that they reference (via CreateObject) a custom DLL we developed in VB6, which - now that I think of it - could be part of the issue. The reference to CreateObject could be creating a conflict somewhere - I don't see how calling a generic VB6 DLL would cause a conflict. I will recreate the circumstances and report the details to the forum with the results and findings.
- Don |
|
|
|
Re: .NET Framework compatibility
Posted: 13 Mar 06 1:08 AM
|
Don,
Not sure what you're seeing and I'm curious about your symptoms. However, if you reinstall .NET Framework 2.0 alongside .NET 1.1 try creating a text file in the SalesLogix program directory called "SalesLogix.exe.config" with the following contents:
<?xml version ="1.0"?>
<configuration>
<startup>
<requiredRuntime version="v1.1.4322" />
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>
This will attempt to cause SalesLogix and managed DLLs that run in its operating memory space to stick with the v1.1 version of the .NET runtime even if v2.0 is also installed. I suspect some of your custom DLLs are, or call, managed .NET code as well, otherwise .NET Framework should have no effect.
HTH,
Jon |
|
|
|
Re: .NET Framework compatibility
Posted: 13 Mar 06 2:18 PM
|
Good idea Jon.
Although I would think that Don's problem is something else. I have .NET 2.0 running on almost all my machines with no issues. But who knows, maybe there's something his DLL is doing or something. If he hadn't mentioned that the DLL is VB6 then I would think the supportedRuntime would do the trick for sure.
-Ryan |
|
|
|
Re: .NET Framework compatibility
Posted: 13 Mar 06 7:00 PM
|
We've seen some plug-ins fail for the same reason (upgrading to .NET Framework v2), notably a premier third party dashboard technology that uses a managed codebase. The dashboard product's company recently worked around the problem with a product update, last I heard. Unfortunately, the third party was not at fault. Microsoft simply did not live up to its promise in releasing version 2 of the .NET Framework as 100% backwards compatible to 1.1, despite their claims. There are some methods and/or properties on some classes in the framework that are just plain missing (rather than not implemented or pseudo-implemented). I think in this case it was in the Windows Forms namespace.
At any rate, SalesLogix 6.2.3 does not implement managed code in the LAN Client. There may have been some subtle tweaks to support .NET integration as a precursor to what's coming in version 7 (grin ... hope ya'll are coming to Insights), but managed code is not in use in any released version of the LAN Client yet. Upgrading to .NET 2.0 will only break third party plug-ins if any at all, and then it is an issue between Microsoft and the third party plug-in.
The .config file workaround is a workaround, not a solution. Disabling the v2.0 upgrade is never a solution, in my opinion. .NET 2.0 is a solid framework, generally speaking, and v1.1 will probably be considered legacy by Microsoft once Windows Vista is out. Hopefully by then a .NET v2 update will come out that will finish off compliance of the backward compability standard that they set up for themselves.
Jon |
|
|
|
Re: .NET Framework compatibility
Posted: 13 Mar 06 10:24 PM
|
From what I've found, the place where .NET 2.0 causes a problem is when loading a 1.1 assembly via an interop layer, such as a COM add-in of some kind or other COM exposed layer loaded by an unmanaged application. In these cases the .NET 2.0 framework will be used to load the assembly instead of the .NET 1.1 framework - such as described here:
http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetdep/html/netfxcompat.asp
IIRC (and it's been a little while since I tested this), then I seemed to have the most problems with .NET 2.0 on the machine when loading a COM-exposed 1.1 assembly when the either the assembly is loaded in the GAC and depends on a assembly outside the GAC, or the other way around (like I said, it's been a little bit since I tested that and details are fuzzy)
If Don's case is that the VB6 DLL late-binds to a COM-exposed .NET 1.1 assembly then this could be his problem (or maybe interacts with a .NET 1.1 application in some way). If this is the case then his only route might be to force the 1.1 framework via supportedRuntime (which I agree completely sucks)
-Ryan |
|
|
|
Re: .NET Framework compatibility
Posted: 13 Mar 06 10:38 PM
|
I can definitely see how Microsoft's interop tweaks could affect things after the v2.0 upgrade.
In the case of the third party I spoke of, however--which I admit is probably not related to Don's problem but just a curious observation per the thread topic--as I understood it the problem was specifically a missing property or method in a common class in Windows Forms that vanished in 2.0 beta and was promised by Microsoft to be added by gold but it never happened. I will have to go back and reproduce it again and Google the missing class member for mention of this to be of any value, except to say that, for this reason, there could be a number of similar incompatibilities in v2.0, however rare.
UPDATE:
I found the member in question. It was Control.AutoSize. This member is mentioned here (below). Essentially there was a same-name member added to the Control class in v2 that did not exist in v1.1 and therefore a conflict resulted since the plug-in's implemented assembly did not (could not) declare the new keyword in the inherited class.
Breaking Changes in .NET Framework 2.0
http://msdn.microsoft.com/netframework/programming/breakingchanges/default.aspx
|
|
|
| |
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|