.NET framework targeting

CSXPJC

We have a build server with .NET 4.6.1 installed on which we build a .NET 4.6.1 targeted application (server 'A'). We also have a build server on which is installed .NET 4.6.2 where we build a .NET 4.6.2 targeted application (server 'B'). We want to move the build for the .NET 4.6.1 application to server 'B' where the build will continue to target 4.6.1 for that application. We will then have a server with .NET 4.6.2 installed that is building both .NET 4.6.1 and .NET 4.6.2 target applications.

Server 'B' also has SmartAssembly 6.9 installed - this is working fine on the .NET 4.6.2 application. There are concerns that if we build and obfuscate the .NET 4.6.1 application on server 'B' that during obfuscation references might be altered to point to .NET 4.6.2 versioned specific assemblies thereby making the application unable to run on machines with only .NET 4.6.1 installed. Or even worse, the application might run but untimately fail when it tries to perform a specific operation for which, due to SmartAssembly changing reference versions, a particular piece of functionality doesn't work.

There is anecdotal evidence from a team within our company that this was a problem when obfuscating .NET 4.0 targeted applications on a server with .NET 4.5 installed.

Is this a real concern? Will SmartAssembly change referenced .NET dll versions?

Thanks

Jessica R

Hi and thanks for your post!

For this situation, you wouldn't need to install .NET 4.6.2 onto server 'B', however, in order for it to be able to build both the 4.6.1 and 4.6.2 assemblies, that server would still need to have the .NET 4.6.1 SDK installed (in additional to the .NET 4.6.2 SDK). The SDKs provide the reference assemblies that SA requires for building.

SmartAssembly does know to use the reference assembly folder with the correct version when building, so it will use the .NET 4.6.1 SDK folder for building .NET 4.6.1 assemblies and the .NET 4.6.2 SDK folder for building .NET 4.6.2 assemblies.

There are some known problems which may have been what you experienced previously. One was an issue in an older version of SmartAssembly when trying to build .NET 4.5.1 assemblies where it would still use the .NET 4.5 folder-this would then cause build errors if a .NET 4.5.1 type was used that didn't actually exist in .NET 4.5. However, this issue has been resolved in SA 6.9 though so that SA uses the correct folders for .NET 4.5.1 and higher. Another known issue is with ILMerge (and possibly other tools that process an assembly before you run it through SA) - if you process an assembly through ILMerge and don't specify the framework, the resulting assembly could be built with the wrong version which could create similar problems to the previous issue. (For this issue, you just need to make sure to specify the version when you run ILMerge.)

With that though, SA does know to use the correct versions of reference assemblies so there shouldn't be any issues unless there's something odd about the original assembly's references--if this is the case, we're happy to help with tracking that down!

CSXPJC

Great, thanks.

We've done as suggested and evrything appears to be working fine.