MS Visual Studio 2022 (currently v17.4), e.g. within a simple C# .NET console app, becomes nearly unresponsive, taking multiple seconds while typing a few characters into the editor.

Solution/Workaround

1. Watch the current background tasks VS is running at the moment (bottom left), and make sure every task finishes within a few seconds.
   • If you experience e.g. a very long indexing of project files, this could be suspicious.
2. Reset VS settings to default:
   • devenv /ResetSettings
   • devenv /ResetUserData
3. Delete .vs subfolder of your project
4. Disable project cache:
   • Tools -> Options -> Environment -> Preview Features -> Use the project cache …

This should improve the editor’s AutoComplete feature a lot.

If not, have a look at the references, there are a few additional option tweaks which might be helpful.

References

https://stackoverflow.com/questions/72237599/how-to-disable-that-new-filecontentindex-folder-and-vsidx-files-in-vs-2022

https://superuser.com/questions/1663409/how-to-fully-reset-all-visual-studio-settings-to-factory-defaults

https://stackoverflow.com/questions/73787513/what-is-vsidx-in-visual-studio-and-why-is-it-autogenerated

https://www.reddit.com/r/VisualStudio/comments/zm252q/vs_2022_very_laggy_and_slow/

Get it via NuGet or Github.

[github-commits username=”DXSdata” repository=”AutoMapper” limit=”10″][:]

The following example extends this functionality by allowing access if the client user resides in the local network.

namespace myns.Helpers
{    
    public class AuthorizeOrInternalAttribute : TypeFilterAttribute
    {
        /// <summary>
        /// If set, user is able to access the controller method if logged in or requests from LAN
        /// </summary>
        public AuthorizeOrInternalAttribute() : base(typeof(AuthorizeOrInternalFilter))
        {            
        }
    }

    public class AuthorizeOrInternalFilter : IAuthorizationFilter
    {        
        public void OnAuthorization(AuthorizationFilterContext context)
        {
            var internalIps = new[] { "::1", "127.0.0.1", "192.168." };
            var remoteIp = context.HttpContext.Connection.RemoteIpAddress.ToString();
            var isLAN = internalIps.Any(iI => remoteIp.StartsWith(iI));
                        
            if (!isLAN)
                if (context.HttpContext.User == null)
                    context.Result = new ForbidResult();
        }
    }



}

[HttpGet("[action]")]
[AuthorizeOrInternal]
public User Details()
{
    return this.GetAnyDetails();            
}

Reference[:]

I partly implemented the openTRANS v2.1 definitions in C# .NET Standard 2.0.

Get it on Github and NuGet.

[github-commits username=”DXSdata” repository=”openTRANS” limit=”10″][:]

Get it via GitHub.

[github-commits username=”DXSdata” repository=”explorerFilePreview” limit=”10″][:]

Add e.g. to your ExtensionMethods:

private const int EM_SETCUEBANNER = 0x1501;
[DllImport("user32.dll", CharSet = CharSet.Auto)]
private static extern Int32 SendMessage(IntPtr hWnd, int msg, int wParam, [MarshalAs(UnmanagedType.LPWStr)]string lParam);

public static void SetPlaceholder(this TextBox box, string text)
{
    SendMessage(box.Handle, EM_SETCUEBANNER, 0, text);
}

Result:

Reference[:]

Goal

We want to include an unmanaged DLL file to our VS project which produces a NuGET .nupkg output. We are using .NET Framework v4.6.1 in this case (should be equal with similar versions).

The unmanaged file should be included within the generated .nupkg automatically. Referencing the NuGET package in other projects, the unmanaged file should also be copied to that project’s output automatically.

Steps

We don’t need a .nuspec file. Instead, we edit the .csproj file of the project which produces the .nupkg.

Before the final “project” end tag, we add or append/edit the ItemGroup tag like:

<ItemGroup>
<None Include=”unmanaged.dll” Pack=”true” PackagePath=”build\”>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Include=”unmanaged.targets” Pack=”true” PackagePath=”build\”>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>

With this configuration, the 2 mentioned files will be added to the .nupkg file, under a separated “build” subfolder.

The file unmanaged.dll should exist in your project’s root directory. In addition, we create a new file “unmanaged.targets” there, and insert:

<Project xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>
<ItemGroup>
<NativeLibs Include=”$(MSBuildThisFileDirectory)**\*.dll” />
<None Include=”@(NativeLibs)”>
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>

The .targets file ensures that your unmanaged file is copied to the Debug/Release output of the project where you are actually using your NuGET package.

Build your NuGET project, the .nupkg file should be created and contains your unmanaged file.

Update: Publishing unmanaged DLL via ClickOnce

If you have finished the steps above, the unmanaged file is copied to Debug output, but will not yet be published if you deploy your final app via ClickOnce method. You might get FileNotFoundExceptions.

To achieve this, you have to add a link to your unmanaged file from your ClickOnce project.

So one way would be to install your NuGet package, then go to your project’s solution and add a reference to an existing element, which is your unmanaged file within your project’s “packages\MyNugetModule” folder. I recommend adding it as a link instead of the file (see the dropdown in the dialog!). In the file’s properties, choose “Copy if newer”.

Finally, the file should be included in your ClickOnce deployment.

References

https://stackoverflow.com/questions/19478775/add-native-files-from-nuget-package-to-project-output-directory

https://stackoverflow.com/questions/51217832/including-unmanaged-dll-in-nuget-package-using-csproj

 [:]

It offers a more flexible re-generated DbContext.cs file and you can simply append it to your existing DB scaffolding command.

Optimizes generated DbContext output of “dotnet ef dbcontext scaffold”:

• Makes DB schema changeable at runtime”
• Removes OnConfiguring method (including connectionString), so you can implement your own partial OnConfiguring method outside the generated context.
• Optional parameter –winforms optimizes all generated .cs files in the context file’s folder for usage in Windows Forms (grids etc).

Read more and find the latest infos on Github.

Latest commits:

[github-commits username=”DXSdata” repository=”DotnetEfDbcontextConverter” limit=”10″][:]

You can get it via NuGet for any .NET framework type.

Example

Let’s suppose we have a simple DB table User. Each user belongs to a UserGroup and owns several items, stored in UserItem. The tables are “connected” via common IDs and SQL foreign keys. The DB classes were generated via common tools like “dotnet ef scaffold”.

We want to get an overview of the users, including a property of the parent (UserGroup.Name) and a sum of the user’s items. The table is huge, so the whole preparation and calculation should be done by the server to reduce network traffic.

The data will be stored in a flat ViewModel class UserView, which contains the same structure as User, but with 2 additional fields, UserGroupName and UserItemSum.

First we prepare AutoMapper:

//using AutoMapper;
Mapper.Initialize(cfg =>
{
    cfg.CreateMap<User, UserView>()
      .ForMember(uview => uview.UserItemSum, opt => opt.MapFrom(user => user.UserItem.Sum(item => item.Number)))
});

Create the context instance for DB access:

var db = new mydbContext();

var dto = db.User.ProjectTo<UserView>().ToList();

//example for proceeding
myBindingSourceForDataGrid.DataSource = dto;

…and that was about it. We do not need any more Include() of subtables, Where(), Select() or anything else, and the whole query is run on the server side (the SQL server).

AutoMapper is smart enough to recognize that the UserView.UserGroupName column should belong to the user’s UserGroup.Name property.

In CreateMap(), we just need to tell how it handles the UserItemSum column.

Taking a look at the SQL query log, we see that the query in fact contains only the needed data:

SELECT `User`.`Fullname`, `User.UserGroup`.`Name` AS `UserGroupName`, `User`.`id`, (
    SELECT SUM(`item`.`Number`)
    FROM `mydb`.`UserItem` AS `item`
    WHERE `User`.`id` = `item`.`userId`
) AS `UserItemSum`
FROM `mydb`.`User` AS `User`
INNER JOIN `mydb`.`UserGroup` AS `User.UserGroup` ON `User`.`UserGroupid` = `User.UserGroup`.`id`

References

http://docs.automapper.org/en/stable/Queryable-Extensions.html

 [:]

In this case, I created a .NET project with MySQL DB about 10 years ago, using mainly DataSets. They were quite easy to handle with VS GUI tools.

Nowadays, MySQL VS and Connector Add-Ins seem buggy and error-prone. DataSets are not recommended any more at all, MS came up with platform-independent .NET Core and .NET Standard, and the EntityFramework scaffolding works quite well in .NET Core. So basically, it would be a good idea to migrate DataSets to Core/Standard DB entity scaffolding.

Situation

The main problem: DataSet/TableAdapter methods, commands and properties must be replaced manually because it’s a completely different approach to access data. In large projects, this can take weeks or even months. So I was looking for a way to be able to use both options in parallel within the same VS solution, for a simpler and smoother transition which does not block other project feature developments.

Basically, we will add a .NET Standard project to our existing .NET Framework project. The new one will contain the DB classes generated by .NET Core scaffolding. Running it in parallel with DataSets will be a bit tricky.

Steps

First, install the latest version of Visual Studio and .NET Framework and Core SDKs.

Make sure your existing .NET Framework project(s) version is at least 4.6.1 to be compatible with Standard and Core.

Add a new .NET Core class library project to your solution, we will call it “DB”. Edit DB.csproj, change TargetFramework to “netstandard2.0” to be make it most compatible, then restart VS.

Install packages via NuGet for DB:

• MySql.Data.EntityFrameworkCore
• MySql.Data.EntityFrameworkCore.Design
• (NETStandard.Library)

Create an empty project folder “Models”.

Because we created a library, to run the scaffolding .NET Core also needs an application project (see notes below for details).

Add a new .NET Core console application named “DbBuildTmp” and install NugetPackes

• MySql.Data.EntityFrameworkCore.Design
• (Microsoft.NETCore.App)

In DbBuildTmp, reference project DB.

Open developer command prompt and navigate to the DB folder.

Run the scaffolding command to generate classes of your existing database:

dotnet ef dbcontext scaffold "server=myserver;port=3306;user=myuser;password=mypw;database=mydb" MySql.Data.EntityFrameworkCore -o Models -f --startup-project ..\DbBuildTmp

You should now have one C# class file per DB table within the Models folder, and an additional mydbContext.cs file.

Accessibility from .NET Framework project

To be able to simply access the new EF class structure from your existing project, e.g. via “new mydbContext().mytable.First().id”, we need a few more steps.

Important: Ensure your previously installed MySQL Connector (and therefore MySql.Data reference) version matches the NuGet MySql.* package versions exactly (e.g. 8.0.13)!

Add a reference to your new DB project.

Add in both existingProject.csproj and DB.csproj (within <PropertyGroup> element):

<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

With these properties set, the compiler seems to solve versioning issues better itself, and also copies the .NET Standard/Core output with (most, not all?) needed references.

For your existing Framework project, install NuGet package

• Microsoft.EntityFrameworkCore
• and all suggested dependencies.

Note: the packages’ version must match the version which is referenced to by MySql.Data.Entity* packages in the DB project exactly!

Now you should be able to get some test data e.g. via your original Program.cs:

var testdb = new DB.Models.myContext();
Console.WriteLine(testdb.myTable.Find("myId").SomeColValue);

If versioning conflicts occur, empty your projects’ bin/obj folders and double-check the (sub)-references of all your NuGet packages compared to non-Nuget references like maybe MySql.data.

One error which also might occur is “unknown: providers” – on runtime, when accessing the DbSet property the first time. Have a look at existingProject.csproj. The EntityFramework element might contain a “providers” tag which is useless for MySQL; delete the full providers tag and recompile.

Using original connection string

The class generator sets the connection data within the mydbContext’s “OnConfiguring” method, which is fine for testing, but we want to use the same connection string for DataSet and EF entity access, set in the Framework project’s Properties.Settings file.

At the moment, there seems to be no way to prevent the CLI scaffolding command from generating this method.

In my opinion, the least inconvenient way is to create a separate “partial class” which stays out of the Models folder, but uses the same namespace. So you can simply move this method out from the mydbContext file to the a place where it cannot be overwritten. Re-Running DB scaffolding will recreate the method but at least you get a compiler error message (“duplicate”) as a reminder to delete it again.

In Framework project’s Program.cs file, you can set e.g. some static variable like

DB.MyStaticCommonFile.connstr = Properties.Settings.Default.OriginalConnStr;

Then modify DB project’s DbContext OnConfiguring method like

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    if (!optionsBuilder.IsConfigured)
    {
        optionsBuilder.UseMySQL(MyStaticCommonFile.connstr);
    }
}

Some notes

Usually, it should also be possible to use the existing Framework 4.x project as “startup project” for DB scaffolding. In fact, this might end with an MSBuild error “MSB4006 / GetEFProjectMetadata”. So we have to use the additional .NET core console application project until this is fixed.

Usually a good alternative to the original MySQL EF packages for Core is Pomelo, it was way less buggy than the original packages months ago. Anyway, we have to use original MySQL EF here to be compatible with the existing MySql.Data in the Framework project. Pomelo contains a dependency to MySqlClient which causes a huge load of version and naming conflicts if included.

References

https://docs.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db

https://stackoverflow.com/questions/43837638/how-to-get-net-core-projects-to-copy-nuget-references-to-build-output/43841481

 [:]