This question is locked. New answers and comments are not allowed.
My question is simply:
Can I statically reference an older version of Open Access, but still have a newer version of Open Access installed?
As a followup:
If not, can I install two versions of Open Access side-by-side on a development machine?
Background:
Our solution currently references Open Access 2013.1.418. We have copied all necessary Open Access assemblies to the BIN folder of our solution. All references in our projects are static references to those copies of the assemblies. We still have that version of Open Access installed on our development machines. The solution builds perfectly and can be deployed, installed, and used by our testing department without their need to install Open Access. This is all as expected and desired.
An issue has arisen though that we want to upgrade our development machines to the latest release of Open Access. This is so that we can see how it works with our solution, etc. But as soon as we upgrade the installed version of Open Access, our solution will not build until we also upgrade any references to the newer version (or downgrade Open Access back to the version we reference). There are a number of other threads in these forums dealing with that issue where someone accidentally got the installed and referenced versions out of sync.
Our problem comes in that we can not use the standard resolution of simply upgrading our references.
The reason is that we develop in multiple versions of our application simultaneously.
We would like to use the latest Open Access in Version 3. But Version 1, and usually Version 2, can only use the version of Open Access in place and referenced at the time of its initial development (prior to testing and/or release). It is simply not an option to upgrade Open Access references in a released version (Version 1) simply to use the latest Open Access in a development version (Version 3). Thus we are essentially stuck on the older Open Access version for all versions of our solution if we need to develop on more than one version of our solution.
In reviewing related threads here and other research, this thread on Stack Overflow seems to point to the clearest reason why, currently, it is not possible to reference one version, but have a different version installed. In short, the Open Access assemblies are strongly named/signed (a good thing), but this causes the .NET CLR to only load the Open Access assemblies from the GAC (a bad thing since that's not the version we reference).
My thought on a possible solution is to allow side-by-side installations of Open Access. This should allow both versions to be installed in the GAC and thus the correct version to be referenced by our solution in a development environment. Are side-by-side installations currently possible?
Can I statically reference an older version of Open Access, but still have a newer version of Open Access installed?
As a followup:
If not, can I install two versions of Open Access side-by-side on a development machine?
Background:
Our solution currently references Open Access 2013.1.418. We have copied all necessary Open Access assemblies to the BIN folder of our solution. All references in our projects are static references to those copies of the assemblies. We still have that version of Open Access installed on our development machines. The solution builds perfectly and can be deployed, installed, and used by our testing department without their need to install Open Access. This is all as expected and desired.
An issue has arisen though that we want to upgrade our development machines to the latest release of Open Access. This is so that we can see how it works with our solution, etc. But as soon as we upgrade the installed version of Open Access, our solution will not build until we also upgrade any references to the newer version (or downgrade Open Access back to the version we reference). There are a number of other threads in these forums dealing with that issue where someone accidentally got the installed and referenced versions out of sync.
Our problem comes in that we can not use the standard resolution of simply upgrading our references.
The reason is that we develop in multiple versions of our application simultaneously.
- Version 1 has been released to customers and is in use in a production environment. Occasionally bugs are found that require fixes and patches/service packs/etc. This necessitates further development in this version.
- Version 2 is unreleased but in active testing by our testers. We frequently will need to fix bugs that arise in it and give testers a new version. Again, this necessitates further development in this version.
- Version 3 is a future dev branch that we are adding new features to but has not been sent to testers yet.
We would like to use the latest Open Access in Version 3. But Version 1, and usually Version 2, can only use the version of Open Access in place and referenced at the time of its initial development (prior to testing and/or release). It is simply not an option to upgrade Open Access references in a released version (Version 1) simply to use the latest Open Access in a development version (Version 3). Thus we are essentially stuck on the older Open Access version for all versions of our solution if we need to develop on more than one version of our solution.
In reviewing related threads here and other research, this thread on Stack Overflow seems to point to the clearest reason why, currently, it is not possible to reference one version, but have a different version installed. In short, the Open Access assemblies are strongly named/signed (a good thing), but this causes the .NET CLR to only load the Open Access assemblies from the GAC (a bad thing since that's not the version we reference).
My thought on a possible solution is to allow side-by-side installations of Open Access. This should allow both versions to be installed in the GAC and thus the correct version to be referenced by our solution in a development environment. Are side-by-side installations currently possible?
6 Answers, 1 is accepted
0
Accepted
Hello Jeff,
You are raising an important and interesting question - how to have multiple OpenAccess version side by side.
Unfortunately currently there is no easy and clean way to set your development environment this way.
You can start with the guidance found in this article: How to: Use OpenAccess ORM Without Installing It.
My suggestion will be to copy all OpenAccess files in a folder in the solution root rather than inside one of the projects. This way you will be able to reference the same assemblies easier in multiple projects. If you copy the file in the solution root then you have to modify slightly the path to the OpenAccess.targets file in the following manner (see the bolded addition):
After copying and fixing the target import you should set SpecificVersion =True for each of the OpenAccess assemblies in your projects. And if these references are pointing to the default installation directory you will have to change them to point to the newly copied ones.
This way you should be able to use the specific version of OpenAccess regardless of the currently installed one.
You should be able to apply the same trick to all of you product versions.
There are some caveats:
Making different OpenAccess versions work side by side and simplifying the deployment of projects that are using OpenAccess is in the top few item items in our backlog. We will be happy if you share your feedback and experience in this scenario so we can incorporate it when implementing the feature.
If you face any difficulties or you need any further assistance setting up your development environment do not hesitate to contact us again.
Regards,
Viktor Zhivkov
Telerik
You are raising an important and interesting question - how to have multiple OpenAccess version side by side.
Unfortunately currently there is no easy and clean way to set your development environment this way.
You can start with the guidance found in this article: How to: Use OpenAccess ORM Without Installing It.
My suggestion will be to copy all OpenAccess files in a folder in the solution root rather than inside one of the projects. This way you will be able to reference the same assemblies easier in multiple projects. If you copy the file in the solution root then you have to modify slightly the path to the OpenAccess.targets file in the following manner (see the bolded addition):
<Import Project="$(SolutionDir)\OpenAccessAssemblies\OpenAccess.targets" />This way you should be able to use the specific version of OpenAccess regardless of the currently installed one.
You should be able to apply the same trick to all of you product versions.
There are some caveats:
- The installed version of OpenAccess will be the one that will be used when working with Visual Designer and any of the OpenAccess wizards. It is possible that you will use a new feature that is not yet available in the local version of OpenAccess assemblies. Use Visual Designer and wizards with care when working on projects that uses older version of OpenAccess;
- Visual Designer and wizards can change/overwrite the references or OpenAccess.targets import. Before considering the changes you did stable, please verify in Modules view during debug that the right assemblies are loaded.
Making different OpenAccess versions work side by side and simplifying the deployment of projects that are using OpenAccess is in the top few item items in our backlog. We will be happy if you share your feedback and experience in this scenario so we can incorporate it when implementing the feature.
If you face any difficulties or you need any further assistance setting up your development environment do not hesitate to contact us again.
Regards,
Viktor Zhivkov
Telerik
OpenAccess ORM Q2 2013 brings you a more powerful code generation and a unique Bulk Operations support with LINQ syntax. Check out the list of new functionality and improvements shipped with this release.
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 02 Aug 2013, 01:18 PM
Viktor,
Thank you for your detailed reply. We have, through trial and error, done some of what your link and reply state. But not all. For instance, we have copied the files into a folder in the solution root and referenced those files rather than what is installed. But we have not taken the extra steps of modifying the OpenAccess.targets and such. What we've done so far has allowed us to build the solution on our build server (it has OpenAccess installed) and allow our testers to install and use the product in a release (rather than debug) environment. But your additional insight should streamline some of our process and ensure our build and deploy process is more robust.
I should be able to either this afternoon or next week carry out these suggestions on our solution.
A suggestion for an easier and cleaner way to accomplish this would be the side-by-side installation. Just like I can have both Visual Studio 2010 and 2012 installed in use without one affecting the other, it would be handy to do the same with Open Access. This would allow for referencing the appropriate version in a solution without newer installs being required. This would obviously require some determination of what constitutes an update to an existing installation versus a new, separate installation. Side-by-side would also remove the caveat of the Visual Designer and wizards being newer than the version referenced.
Thanks again and I will update this thread with my results and any additional steps or requirements I encounter.
Jeff
Thank you for your detailed reply. We have, through trial and error, done some of what your link and reply state. But not all. For instance, we have copied the files into a folder in the solution root and referenced those files rather than what is installed. But we have not taken the extra steps of modifying the OpenAccess.targets and such. What we've done so far has allowed us to build the solution on our build server (it has OpenAccess installed) and allow our testers to install and use the product in a release (rather than debug) environment. But your additional insight should streamline some of our process and ensure our build and deploy process is more robust.
I should be able to either this afternoon or next week carry out these suggestions on our solution.
A suggestion for an easier and cleaner way to accomplish this would be the side-by-side installation. Just like I can have both Visual Studio 2010 and 2012 installed in use without one affecting the other, it would be handy to do the same with Open Access. This would allow for referencing the appropriate version in a solution without newer installs being required. This would obviously require some determination of what constitutes an update to an existing installation versus a new, separate installation. Side-by-side would also remove the caveat of the Visual Designer and wizards being newer than the version referenced.
Thanks again and I will update this thread with my results and any additional steps or requirements I encounter.
Jeff
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 05 Aug 2013, 04:21 PM
Viktor,
Following the link you provided for using OpenAccess without Installing, along with your additional notes was successful in accomplishing my goal. I did not need to do anything additional beyond what you mentioned. I now have my solution referencing a specific OpenAccess version and at the same time have a newer version of OpenAccess installed. Previously, this scenario wouldn't allow the solution to build, but it does not properly build and run.
Thank you for your assistance. I look forward to a more streamlined and automatic way of having multiple versions side-by-side.
Following the link you provided for using OpenAccess without Installing, along with your additional notes was successful in accomplishing my goal. I did not need to do anything additional beyond what you mentioned. I now have my solution referencing a specific OpenAccess version and at the same time have a newer version of OpenAccess installed. Previously, this scenario wouldn't allow the solution to build, but it does not properly build and run.
Thank you for your assistance. I look forward to a more streamlined and automatic way of having multiple versions side-by-side.
0
Hi Jeff,
I am glad that you were able to set up your development environment according to your needs.
I will notify you when we have any progress to share regarding the implementation of side by side versioning scenarios.
Regards,
Viktor Zhivkov
Telerik
I am glad that you were able to set up your development environment according to your needs.
I will notify you when we have any progress to share regarding the implementation of side by side versioning scenarios.
Regards,
Viktor Zhivkov
Telerik
OpenAccess ORM Q2 2013 brings you a more powerful code generation and a unique Bulk Operations support with LINQ syntax. Check out the list of new functionality and improvements shipped with this release.
0
Michael
Top achievements
Rank 1
Rank 1
answered on 12 Mar 2014, 02:19 AM
Any chance we can get a version for VB.net for what's here? Almost immediately, this proves useless and my entire application is halted because no matter what I do, my project insists on referencing version 2013 instead of 2014 and I'm hoping that with approach, I can force it to do what it should be doing anyway: http://docs.telerik.com/data-access/developers-guide/integrating-data-access-in-your-solution/external-tools-howto-integrate-enhancer-msbuild
0
Hi Michael,
Based on the provided information, it seems that the issue you are experiencing is the one discussed in support thread 797275.
Regarding the process discussed in this post, let me confirm that the steps for both C# and VB are the same.
In case my assumption about the relation between your inquiry and the issue presented in the support thread is not correct, or if you need additional information about the process described here, do not hesitate to get back to us.
Regards,
Doroteya
Telerik
Based on the provided information, it seems that the issue you are experiencing is the one discussed in support thread 797275.
Regarding the process discussed in this post, let me confirm that the steps for both C# and VB are the same.
In case my assumption about the relation between your inquiry and the issue presented in the support thread is not correct, or if you need additional information about the process described here, do not hesitate to get back to us.
Regards,
Doroteya
Telerik
OpenAccess ORM is now Telerik Data Access. For more information on the new names, please, check out the Telerik Product Map.