Hi

We are upgrading the llblgenpro from v2.6 into v3.1.Because we find the same naming on all SD.dlls both of v2.6 and V3.1, so here will conflict on reference by same naming.

Our application has 60 modules that all reference these dlls. In future, we will produce hundrends modules. The upgrade version become a problem for us.

I really don't think we should be following a policy that means every time we change a version of a dll, then 100s of solutions need to be updated. We should engineer an approach that allows old and new to co-exist. This is why dlls have version numbers after all.

Best regards

Different versions can co-exist on the same machine. Different solutions referencing different versions should work un-affected by other versions.

Walaa wrote:

Different versions can co-exist on the same machine. Different solutions referencing different versions should work un-affected by other versions.

Maybe I didn't express clearly of my thinking, I want to run both version 2.6 and version 3.1 under the same solution and under its same project. Could I do that?

Sorry, but you can't use them (same dlls but with different versions) in the same project.

Different versions of dlls, some things changed, you can't use both at the same time in the same application. What you should do is add a folder to the solution folder on disk and add the runtime dlls to that folder. Then use a file search / replace tool to change all csproj files to reference the dlls from THAT folder.

Next time you want to upgrade the whole solution to a new version, you simply have to update the dlls in that folder. We use the same setup for our unittest projects, and indeed, it otherwise drives you insane. It's really a problem with vs.net to be honest, it has a horrific reference management model. A search/replace tool for files on disk can quickly change the reference folder in the csproj file to the folder where the runtime libs are located. Updating them in one go is then easy.

do the code generation process using the cligenerator tool as well if you have multiple DAL projects. For example, in our unit test solutions, we use many DALs, and we use a .cmd file to call the cligenerator to generate new code for the projects, and we build the runtimes using msbuild and copy the files to the runtime lib folder of the unittest solutions. Then build the unittest solution and run the tests. This makes things very easy to update everything in 1 go: generating and runtime lib versioning.

Mixing different major versions in the same project is not going to work, as you can't assign an instance of type X to a variable of type X', where X is a v2.6 type and X' is a v3.x type.

Otis wrote:

Different versions of dlls, some things changed, you can't use both at the same time in the same application. What you should do is add a folder to the solution folder on disk and add the runtime dlls to that folder. Then use a file search / replace tool to change all csproj files to reference the dlls from THAT folder.

Next time you want to upgrade the whole solution to a new version, you simply have to update the dlls in that folder. We use the same setup for our unittest projects, and indeed, it otherwise drives you insane. It's really a problem with vs.net to be honest, it has a horrific reference management model. A search/replace tool for files on disk can quickly change the reference folder in the csproj file to the folder where the runtime libs are located. Updating them in one go is then easy.

do the code generation process using the cligenerator tool as well if you have multiple DAL projects. For example, in our unit test solutions, we use many DALs, and we use a .cmd file to call the cligenerator to generate new code for the projects, and we build the runtimes using msbuild and copy the files to the runtime lib folder of the unittest solutions. Then build the unittest solution and run the tests. This makes things very easy to update everything in 1 go: generating and runtime lib versioning.

Mixing different major versions in the same project is not going to work, as you can't assign an instance of type X to a variable of type X', where X is a v2.6 type and X' is a v3.x type.

I am very busy yesterday and today. So I didn't carefully read your suggestions. I will take some time to read it tommorrow or other day. I am really busy this week.

I'll close this thread for now, and it will be re-opened once you post a reply.

Walaa wrote:

I'll close this thread for now, and it will be re-opened once you post a reply.

I found a strange in *.csproj file:

Please check the llblgenpro dlls information on both of V3.1 and V2.6 below, why V3.1 and V2.6 display the same version number : Version = 3.1.0.0

_LLBlgenPro **V3.1 **dlls information:_ <Reference Include="Northwind.BusinessObjects.Adapter, Version=1.0.4079.26888, Culture=neutral, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version3\Northwind.BusinessObjects.Adapter.dll</HintPath> </Reference>

<Reference Include="SD.LLBLGen.Pro.DQE.SqlServer.NET20, Version=3.1.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version3\SD.LLBLGen.Pro.DQE.SqlServer.NET20.dll</HintPath> </Reference> <Reference Include="SD.LLBLGen.Pro.LinqSupportClasses.NET35, Version=3.1.0.0, Culture=neutral,

PublicKeyToken=ca73b74ba4e3ff27, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version3\SD.LLBLGen.Pro.LinqSupportClasses.NET35.dll</HintPath> </Reference> <Reference Include="SD.LLBLGen.Pro.ORMSupportClasses.NET20, Version=3.1.0.0, Culture=neutral,

PublicKeyToken=ca73b74ba4e3ff27, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version3\SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll</HintPath> </Reference>

llblgenPro V2.6 dlls information <Reference Include="Northwind.BusinessObjects.Adapter, Version=1.0.4071.22237, Culture=neutral, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version2\Northwind.BusinessObjects.Adapter.dll</HintPath> </Reference> <Reference Include="SD.LLBLGen.Pro.DQE.SqlServer.NET20, Version=3.1.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version2\SD.LLBLGen.Pro.DQE.SqlServer.NET20.dll</HintPath> </Reference> <Reference Include="SD.LLBLGen.Pro.LinqSupportClasses.NET35, Version=3.1.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version2\SD.LLBLGen.Pro.LinqSupportClasses.NET35.dll</HintPath> </Reference> <Reference Include="SD.LLBLGen.Pro.ORMSupportClasses.NET20, Version=3.1.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\External\ThirdParty\llblgenpro\Version2\SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll</HintPath> </Reference>

What's in the csproj file is what SHOULD be referenced, the hint path is a hint. The dll itself might be different (on disk). v2.6 dlls have v2.6.0.0 as version, not 3.1, rightclick the dlls in windows explorer to check

Otis wrote:

What's in the csproj file is what SHOULD be referenced, the hint path is a hint. The dll itself might be different (on disk). v2.6 dlls have v2.6.0.0 as version, not 3.1, rightclick the dlls in windows explorer to check

You can see my questions on attachment solution.

Specify 'SpecificVersion' as 'true' in the csproj files (inside vs.net).

Anyway, I looked into your attachment, all dlls have the proper version as you could have checked yourself. VS.NET loads them up, and as you didn't specify 'specific' version to true, it will just load the latest one and reference that one in all.

Yes, that's crap, but it's a problem with VS.NET, not something we can solve. The workaround is: specify 'specific version' to true. But IMHO you should migrate everything over, and do NOT use both versions in the same application. The main reason is that it will go wrong somewhere and it will give weird errors which will take a lot of time to solve. Please, save yourself and us that time and don't mix versions.