Avoid support for VS 2022

[ErikEJ]

No description provided.

[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.

[Technocrux]

@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.

I had been using GenerateViews from EF 6 Power tools, I cannot install EF 6 power tools on 2022 VS edition, any alternate?

[ErikEJ]

Yes, read through this issue.

[Technocrux]

Anything I can do to help :) I saw the whole thread but could not got a clue if we are avoiding it or also giving a solution to it as well for those who still want it. Lets say I take the code and build locally, can I do it again, any guide, else I have installed 2019 to side by side, only for generating views, my bad, may be later on Upgrade to EF Core and get rid of this odd flow

[kev160967]

Anything I can do to help :) I saw the whole thread but could not got a clue if we are avoiding it or also giving a solution to it as well for those who still want it. Lets say I take the code and build locally, can I do it again, any guide, else I have installed 2019 to side by side, only for generating views, my bad, may be later on Upgrade to EF Core and get rid of this odd flow

You should consider using @CZEMacLeod 's package if all you are doing is generating views. My scenario was an EDMX model being used to generated classes and a context. My context was ObjectContext based but it would work equally well with DbContext. My views are now generated automatically on every build, so no more forgetting to use the menu and wasting time doing a build and starting a debug session only to find your views are out of date.

[ErikEJ]

@Technocrux See #86 (comment) and #86 (comment) here

[ghost]

@kev160967 Hi, We are also using the ObjectContext (EntityFramework 6.0.0.0 ). Could you please help me, how to solve the issue that explained by @CZEMacLeod ? #86 (comment)

[kev160967]

@avmakesh this reply from @CZEMacLeod says it all really. If you make those changes to your project file it will cause the views file to be generated automatically whenever you build your project, either locally or on a build server. You will need to manually remove the existing file that you've been generating from the power tools as well, otherwise you'll get a clash.

In my case I'd already added the package reference via the nuget console, so I simply had to add the following block to my project file:

    <EntityView Include="SaturnEntities.edmx">
      <Generator>
      </Generator>
      <CustomToolNamespace>Saturn.Data.Model</CustomToolNamespace>
    </EntityView>

The other section in the linked reply was because I have some additional locally written t4 files producing additional output from the EDMX file - you won't need this if you're just using the native t4 generation

[Angry-Emu]

We currently use this tool to create views by right clicking on the DBContext. There is no EDMX file in our solution. Would the above MSBuild solution work for that?

[CZEMacLeod]

@Angry-Emu The process uses an EDMX file to generate the views - the original extension actually generates the EDMX first, then the views from that.
In the samples, there is code showing how to export your EDMX from a code-first type scenario (or basically any DBContext).

[ErikEJ]

@CZEMacLeod Thanks!

[jtrout]

The other section in the linked reply was because I have some additional locally written t4 files producing additional output from the EDMX file - you won't need this if you're just using the native t4 generation

@kev160967 I'm not doing anything outside the native t4 generation, but I did still need to leave the EntityDeploy step in or my OData controllers would return "Unable to load the specified metadata resource" when trying to load the data. Everything went back to working properly as soon as I returned that step. But having the two steps referencing the same file meant the file was duplicated in my Solution Explorer. Do you have that same issue?

Thanks!

~Justin

[kev160967]

The other section in the linked reply was because I have some additional locally written t4 files producing additional output from the EDMX file - you won't need this if you're just using the native t4 generation

@kev160967 I'm not doing anything outside the native t4 generation, but I did still need to leave the EntityDeploy step in or my OData controllers would return "Unable to load the specified metadata resource" when trying to load the data. Everything went back to working properly as soon as I returned that step. But having the two steps referencing the same file meant the file was duplicated in my Solution Explorer. Do you have that same issue?

Thanks!

~Justin

Yes, now you mention it I do - I noticed it a few weeks ago, but hadn't connected it to the project file changes. It doesn't seem to cause any issues though

[jtrout]

Yes, now you mention it I do - I noticed it a few weeks ago, but hadn't connected it to the project file changes. It doesn't seem to cause any issues though

Awesome, I feel better then :) Thanks!

~Justin