Update problems on productive site

[lc4pro]

Hi,

we have recurring problems with linqConnect updates and the Global-Assembly-Cache. Due to the fact that the linqConnect dll's are installed in the GAC our VisualStudio's always use the last installed version of the dll's.

But this dll's are not automatically copied into the ASP.Net-bin folders.

Due to simpler administration of multiple servers we avoid installing software on our servers and trying to use only the needed dll's in our web projects. But with the linqConnect-dll's installed in GAC some developer forget to update them on new releases and the websites will crash.

Is there a possibility to deactivate the installation into the GAC so the dll the web is compiled with and the published dlls will never change on new updates or is there a way to automatically copy the needed linqConnect dll's on every new release to the publish folder on the develoers pc?

thanks!

[MariiaI]

When developing a WebApplication you can do the following:
- add references from the GAC to your application;
- set the 'Copy Local' property of each Devart assembly to 'true';
- re-build your application.

After these steps, in the bin folder of your application all chosen assemblies will be copied. And after updating LinqConnect and re-building the application all these assemblies will be updated too.
But for WebSite projects, the only way to update LinqConnect assemblies is to copy updated assemblies to the bin folder of the project.

[lc4pro]

After some thinking and some trying we are cleaning the GAC and machine.config of our development machines. This gives us back the full control over the versions that are used for compilation on the developers machine and on the servers. No automatic override of any version.

Now it would be extraordinary nice if you guys could add a option to the linqConnect setup/update to prevent updates to the GAC and machine.config!

Is something like that possible?

Thanks!

[MariiaI]

Thank you for your comment. We will consider adding this option into the installation in the future.

[lc4pro]

Back again!

After the last LinqConnect Update we had another edition of dancing around the GAC.
It's terrible!

If we clean the GAC from Devart Assemblies and Devart Policies we will be able to have different versions of LinqConnect on different developers and productive sites. But then tools like EntityDeveloper woun't work any more.

My colleagues are realy not happy about any linqconnect update!

Please provide a install way without gac!

[MariiaI]

We are investigating the possibility of adding this option into the installation, but we can't tell any timeframe at the moment.

[lc4pro]

And Back again.

but with a solution

Still struggeling with GAC and the Policies stored by the setup routine we've come up with the idea to use virtual machines for the setup and generation with entity developer and banned LinqConnect setup from our development systems. From the virtual machines you can get the current dll's and use them in the development environments without having any more troubling policies in your way.

Currently we are working with oracles virtualbox because you can switch betweene snapshots to have multiple linqconnect versions around. For now works pretty well.

greetings

[MariiaI]

Thank you for sharing the workaround for cases with multiple versions of Devart products. While such option is not yet implemented in our installation, your solution may be useful to other users.