Avoid support for VS 2022

[ErikEJ]

[bwolven]

Please Add support for the 3.1 preview version.

[ErikEJ]

@bwolven What do you actually need this extension for?

[ErikEJ]

@bwolven Ping?

[bwolven]

Mainly use it to generate views: Generate Views. As it is now, I have to drop back to VS2019 to generate the views.

[ErikEJ]

@ErikEJ Thanks for the info!

[ErikEJ]

https://github.com/cincuranet/EdmGen2/blob/master/src/EdmGen2/EdmGen2.cs

[CZEMacLeod]

@ErikEJ I've started a little bit of code for an MSBuild Task packaged up as a NuGet that will grab an .edmx from your project (with the build action set to EntityView) and generate an intermediate file with the Views before build and include it with the compile. This would allow the project to be 'always up to date' and even work on a build server, rather than rely on a user manually intervening. It will also work on VS2022. Currently it assumes EF6.4 is your runtime and doesn't do any project scanning or dynamic assembly loading like your add-in does. It also relies on a couple of files I have copied out of this project IViewGenerator.cs, CSharpViewGenerator.cs, and VBViewGenerator.cs. I'm not entirely sure where these files came from originally, and whether they are actually generated from the .tt files or not.

[ErikEJ]

@CZEMacLeod that sounds like a very useful replacement for this crippled tool

[jonreis]

I was just looking for the same thing, to be able to generate views in Visual Studio 2022. It looks like the rest of the EF 6 functionality is already there in VS 2020 i.e. generate model from database.

[CZEMacLeod]

My current task is part of suite of stuff we use internally. Once I have a moment, I'll try and break it out as a separate project/package. It works for me just now, but I'm sure there is a lot of stuff that will need tidying up, and it makes a few assumptions which may or may not be valid for all use cases. I would be more than happy to make this a 'community' project and accept help on making it work more generally for people to use; especially as there are chunks which I don't fully understand as it is ;) (such as the *ViewGenerator classes mentioned previously)

[CZEMacLeod]

A first draft of my MSBuild based GenerateViews task is now online at CZEMacLeod/C3D.MSBuild.Tools.EF6.GenerateViews and the package is at C3D.MSBuild.Tools.EF6.GenerateViews. It makes quite a few assumptions, but there are a couple of sample applications available which show it working. The main thing is it pulls a direct reference to EF6.4.0 and loads that DLL into the MSBuild application. Also it assumes SQL Server, as it doesn't have any other providers loaded into memory. It would probably be possible to make this out of task and do some kind of cross appdomain work, but I developed this for my personal use case. Feel free to fork, and submit pull requests. I am happy to take all the help I can get on this.

[ErikEJ]

@bwolven @jonreis Would be great if you could give this build task a try!

[kev160967]

@CZEMacLeod Will this work with an edmx file that generates an ObjectContext based model? We've currently got one large project that is still stuck with ObjectContexts rather than using a DbContext. I noticed your samples and Readme.md both refer to DbContext?

[CZEMacLeod]

@kev160967 I'm not entirely sure. The commands invoked under the bonnet are basically the same as with the powertools command, but you would have to generate the EDMX file somehow. I am not sure of the way to do that with an ObjectContext. The EdmxWriter object supports writing from a DbContext or a DbModel.

[kev160967]

@CZEMacLeod Thanks for the reply. I do have an EDMX file, its just configured to produce an ObjectContext model, so I should be fine - I'm currently creating the views manually with the powertool, so a build step would be a great improvement, even if the move to VS2022 wasn't forcing my hand. I'm currently working on a different project, but hopefully I'll have a chance to check out the tool later today.

[jonreis]

@CZEMacLeod thank you for creating the task! It worked well for me. @ErikEJ sorry it took me this long to try it out.

For this to work I had to have both EntityDeploy and EntityView. Otherwise the csdl, msl, ssdl files do not get embedded

<EntityDeploy Include="Model.edmx">
  <Generator>EntityModelCodeGenerator</Generator>
  <LastGenOutput>Model.Designer.cs</LastGenOutput>
</EntityDeploy>
<EntityView Include="Model.edmx">
  <Generator></Generator>
  <CustomToolNamespace>Connexion.DataLayer</CustomToolNamespace>
</EntityView>

[CZEMacLeod]

@jonreis I am using code first in my case, so I don't embed the edmx/csdl/msl/ssdl files at all, but you can absolutely have both EntityDeploy and EntityView at the same time. I'm glad it is working for you. It is still a pretty rough/barebones implementation, but if there are any improvements needed, feel free to raise an issue or even a PR if you feel like contributing code 😄

[alpSaral]

I've been using this tool to create pre-views for years. Thanks for your efforts.

I use a little code that I derive from the DefaultDbModelStore class in my projects to generate EDMX.

If the build date of the project with the DbContext class is older than the build date of the application project, it creates the new EDMX file one time.

It works great this way. Please add VS2022 support.

Thanks.

[ErikEJ]

@alpSaral please try out the solution mentioned above, I am reluctant to update a tool with just one usable feature

[kev160967]

Sorry for being dense, but I'm not sure how to set this up. At the moment we have a VB project, .Net 4.7,2, with the EDMX file in it, and several T4 files that generate the context, data classes and some interfaces. Currently when the model is updated we need to right click on the EDMX and use the generate views feature. This is the part of the project file that controls the code generation:

    <EntityDeploy Include="SaturnEntities.edmx">
      <Generator>EntityModelCodeGenerator</Generator>
      <LastGenOutput>SaturnEntities.Designer.vb</LastGenOutput>
      <CustomToolNamespace>Model</CustomToolNamespace>
      <RunCustomToolOn>EntityPartials.tt%3bSaturnEntityGenerator.tt%3bSaturnEntityInterface.tt</RunCustomToolOn>
    </EntityDeploy>

How would I add a build step to generate the views whilst maintaining the existing code generation?

[ErikEJ]

@madskristensen what is the timeline for support for multiple packages for a single id in Marketplace?

[madskristensen]

No word yet from the team. Not this calendar year

[ErikEJ]

@madskristensen Thanks for the candid info. I will make an informed decision. Assume stopping support for VS 2019 and archive is the simplest way forward for now.

[CZEMacLeod]

@kev160967

<ItemGroup>
  <PackageReference Include="C3D.MSBuild.Tools.EF6.GenerateViews" Version="6.4.18">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
  </PackageReference>

  <EntityDeploy Include="SaturnEntities.edmx">
    <Generator>EntityModelCodeGenerator</Generator>
    <LastGenOutput>SaturnEntities.Designer.vb</LastGenOutput>
    <CustomToolNamespace>Model</CustomToolNamespace>
    <RunCustomToolOn>EntityPartials.tt%3bSaturnEntityGenerator.tt%3bSaturnEntityInterface.tt</RunCustomToolOn>
  </EntityDeploy>

  <EntityView Include="SaturnEntities.edmx">
    <Generator></Generator>
    <CustomToolNamespace>Model</CustomToolNamespace>
  </EntityDeploy>
</ItemGroup>

Should be pretty close to getting you going. Now, when building, it will add a file \obj\Debug\net472\EntityViews\SaturnContext.Views.vb file (or similar based on your DbContext name, configuration and framework options) and include it for compilation automatically. You do not need to check this into source control as it will be recreated automatically by the build step. You may need to adjust the CustomToolNamespace to reflect the namespace of your DbContext class.

Hope this helps.

[CZEMacLeod]

@ErikEJ My feeling would be to publish ErikEJ.EntityFramework6PowerToolsCommunityEdition.2019 and ErikEJ.EntityFramework6PowerToolsCommunityEdition.2022 and a new ErikEJ.EntityFramework6PowerToolsCommunityEdition metapackage that included them both for install.

This way you can always install ErikEJ.EntityFramework6PowerToolsCommunityEdition and it will install the appropriate one, and in the future if a single ID can be used, you can simply overwrite it again with both the 2019 and 2022 versions under the original ID.

This would make it most compatible - e.g. if you are using ExtensionPackTools to install the package for your solution.

[kev160967]

@CZEMacLeod Perfect, thank you, all working now

[ErikEJ]

So still no urgency to update and support a VS 2022 version - thans @CZEMacLeod

[Technocrux]

Why are we avoiding it, to be exact. From the above discussion it is unclear whether you are providing a solution/way around or going against it. Please guide.

[ErikEJ]

Because it is a lot of unpaid work for me to do it and support it in the future.

[CZEMacLeod]

@Technocrux Can you let us know which feature/features you are specifically using; there may be alternative ways to achieve what you want in VS2022.