When building a .NET Core AOT application the necessary CLR functionality is, if I understand it correctly, statically linked into the executable. That means that at run time, coreclr.dll is not present as a module and consequently SOS complains that it cannot find a suitable runtime module.
I've tried specifying the extension and CLR path. I can load SOS that way, but so far I haven't been able to run any of the SOS extension commands against an AOT application.
My assumption is that the application still uses the same internal structures such as the managed heap, so I am wondering how these can be debugged in a managed context using SOS (or something similar).
Related
I am very new to .Net6 and .Net Core in general. I understand that it is possible to publish a single file executable but I was a bit surprised to see that the executable is over 180MB even though the application is relatively small.
The application is targeted to Windows x64 only and uses Windows Forms. It has a handful of Forms and uses a JSON library and a CLI library.
There are a number of dependencies which were more-or-less added automatically but I don't know if they are all strictly necessary (e.g the ASPNetCore item)
Bearing in mind that I am only targeting Windows and the featureset used is limited, what are the actions I can take to reduce the size of the executable?
Update
I found https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained which seems to indicate that 'trimming' of WinForms apps is not (yet) possible.
If you already did not, you may switch deployment mode to Framework-dependent from self-contained in publish profile settings, this will exclude .net runtime and will reduce file size dramatically.
However, excluding .net runtime, diverts from its purpose being single file, as you need to install correct runtime to use application. In my opinion, it is worth to keep single exe file with runtime included.
Use This code into your application.
<_SuppressWinFormsTrimError>true</_SuppressWinFormsTrimError>
I've tried to add a new reference to my .NET Core project.The strange thing is that I can access also the projects that are involved in my reference. For this example, i should be able to see the Repository project from service, but should not be able to access Entity Project.However , I can still access the entities object from Service.
How comes ?
References in SDK-based projects are fully transitive so - similar to many other package managers like npm or maven - you all the transitive references are available in the project to make sure the app compiles and runs cleanly, e.g. there are no unresolved references when the dependency is referenced and all assemblies are part of the build output and ready to run. (there may even be conflict resolution applied to conflicting version of assemblies resulting in the generation of binding redirects.)
In previous versions, you would need to install NuGet packages or add additional project references to other projects as well to not get build errors or type load exceptions.
Currently there is no perfect workaround if you want your project to do all the things needed to be able to run and resolve conflicts correctly but not pass transitive references to the compiler.
If you only need a dependency to build a project, but not to run it, you can mark a package or project reference as PrivateAssets="All" (add as attribute to the reference in the .csproj file).
If you want to enforce API usage - e.g. for layered APIs, consider writing a roslyn analyzer that will emit warnings if you reference APIs from places you don't want to. this may be suitable for large projects where tooling is needed to maintain the desired architecture.
I've been working on a VS Code extension that uses Roslyn's workspace API to load a project, at the moment the extension supports .NET Core's old project.json format via the ProjectJsonWorkspace type in the Microsoft.DotNet.ProjectModel.Workspaces package.
With the new tooling changes being released soon I'm keen to support the new .csproj build format but can't appear to find a .NET Standard compliant workspace that supports it.
My understanding is that as it's using MSBuild, I will need to use the MSBuild (Microsoft.CodeAnalysis.MSBuild) package, however it does not support .NET Standard at this moment in time.
What is the best solution if one exists, or will I have to look at creating my own workspace implementation?
Having spoken with various people it appears that there is no .NET Standard compatible MS Build workspace, this can be seen by this answer below to the following GitHub issue:
We haven't done the work to make MSBuildWorkspace work properly with the new MSBuild cross-platform. In the meantime, you might look at what omnisharp does to populate it's workspace.
So it seems that at the time of writing if you want to target the MSBuild workspace in a .NET Standard compliant project then you'll need to build your own custom workspace using Roslyn's workspace API, this is exactly how OmniSharp do it.
Update (16/10/2017):
Whilst MSBuildWorkspace does still not support .NET Standard, there is a library called Buildalyzer that works cross-platform and will generate an AdhocWorkspace for you, allowing you to achieve the same goal.
using Buildalyzer.Workspaces;
// ...
AnalyzerManager manager = new AnalyzerManager();
ProjectAnalyzer analyzer =
manager.GetProject(#"C:\MyCode\MyProject.csproj");
AdhocWorkspace workspace = analyzer.GetWorkspace();
The same library will also allow you to reference a solution file too.
In mvvmcross, I've got a plugin class library which references SQLite for WinRT.
Because of this, I can't build that class library as AnyCPU - instead, I have to reference it as x86, x64 or Any CPU.
This means that new client applications can't just reference a single DLL, but instead individual configurations must reference different input assemblies. Currently I'm doing this by manually editing the .csproj file using conditions.
However, this is a bit error prone (and a bit hard to explain!)
Is there any 'easy' way (1 click way) for client applications to reference the x86/x64/ARM class library trio so that MSBuild then picks the right version at runtime?
If your application does not rely on perfect performance, you might switch to C# SQLite, which is purely managed (Any CPU), so that your class libraries and executable can be set as Any CPU.
Alternatively, you might use Dependency Injection or MEF to inject the assemblies/types of correct bitness at runtime, and in this way at compile time you always work against an interface (which is bitness independent).
As far as I know, MSBuild cannot automatically handle bitness in the way you wanted.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.