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>
Related
I'm trying to deploy a new version of a BizTalk application that contains common orchestrations for several applications (about 20 or so). The new version contains a new orchestration that will be used by several new applications.
When I try importing the msi for the new version I get an error saying:
"Cannot update assembly "[assembly_name]" because it is used by assemblies which are not in the set of assemblies to update.
To update the assembly, remove the following assemblies: "[dependant_assembly1]
[dependant_assembly2]
..."
The BizTalk server is not accessible from a development environment so the application must be updated using the BizTalk administration console. How do I import the updated application without having the remove and reinstall all 20 or so dependant applications?
Thanks
It sounds like you are deploying a new base application with the same version numbers as an existing, older version.
What works for us:
Every time you deploy a new version of your application, increment the version number (since the assemblies are GAC'ed, BTS supports side by side versioning). Any custom assemblies which are changed should also be versioned.
After deploying to your new Application to your local BizTalk, edit the resources to ensure that the correct (latest) versions of all referenced assemblies and bindings etc are up to date (remove old ones, add new ones).
Your common application will now contain both old and new versions of the assemblies. Newer versions of your 'client' applications will use the later version of your base / framework / common application.
Once all dependent applications have been upgraded, you can then remove the old version.
But the real solution seems to be to consider decoupling your applications more, e.g. by using messaging between the applications - this way, you can split out just the schemas as a common reference to the applications.
You can actually hack the deployment process on BT a little bit further than this, if you want to omit the versioning, depending on your access to the actual BT box. (Convince your sysadmin)
If you only have access to the deployment console, stop your dependent applications, remove their reference to the application you want to upgrade, and then deploy over the top, re-add your references and restart the dependent applications. You don't actually have to reinstall.This method is tedious and sucks but it will work. We do this because we have too much in our BT installs to further clutter them with multiple versions of the same app
Here is the hack. You'll need either access to the server (which I know you said you don't have) or the ability to install a service which can receive a dll and preform the below function for you. (I'm thinking you might convince someone to let you set this up) DISCLAIMER, this is not a supported solution and I claim no responsibilty blah blah blah
We do this all the time as we have WAY too many applications to do the first solution. You can slam your newly compiled DLL into the GAC. This NOT recommended by MSFT etc. but we use it in production on servers that have approx. 4000 dlls in the GAC and 1200 BT applications. You'll need to make sure that your metadata is identical i.e. you have the same version, key token etc. and you'll want to have some way of tracking your dlls outside the versioning system (we build a custom deployment infrastructure to do this). Finally once you have pushed your dlls into the GAC you'll need to restart your biztalk services. Make sure you don't have any suspended instances referencing the app you want to redeploy because they will prevent biztalk from pulling a new reference from the GAC when it restarts.
Finally it is important to note that this method will NOT work if your changes require changes in the MessageBox subscrition (things like changes in receive shape filters, correlations etc.) You will also be giving up some functionality in the orchestration debugger if you use this method to change the structure of orchs. The graphic will display the structure of the orchestration when last properly installed but your event list will be correct for the newest version. Finally, if you are replacing schema dlls you want to make doubly sure that you restart services as BT will cache schemas indefinitely.
we have this problem but can't find a solution. We have an application that references something like 24 dlls. When you invoke the application the very first time (after the application is for any reason reset) it takes 25-40 seconds to start loading contents.
This is what we tried:
1. precompile and publish everything in release mode
2. removing pdbs from bin folder
3. put strong named assemblies into GAC
4. set application to debug = false
Please consider that the whole bin folder is composed by 24 dlls for a total size of 28MB. Just 4 of these dlls are strong named and they are more and less 25MB.
Nothing seems changed. What happens EXACTLY when the application is started is something I couldn't find in any book nor forum/blog/post... What can we monitor more to find where the problem is?
Thanks a lot for your help,
Marco
Looks like you will need to use NGen...
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead using the just-in-time
(JIT) compiler to compile the original
assembly.
Precompile the website for deployment, using fixed names, deploy the solution to the server, and then ngen all assemblies in bin
MSDN article on NGen.
Whats the best way to deploy a QT app? I've read the documentation hosted at trolltech but is it better to link with a static library or the dynamic libraries and have the user install the framework? I don't really want anyone using my app to have to download a 160mb framework just to run a simple gui frontend.
On OS X it's a good way to do a dynamic build and post-process the resulting ".app" with the macdeployqt tool which comes with Qt starting with 4.5.
This will copy the Qt frameworks used by your application into the application bundle, which results in a larger package than building a static version of your application.
Here is what you can do to make sure you get the smallest file size possibly in a dynamic build:
First off, make sure you only include the stuff you need (in the project.pro file's QT += core gui network xml lines).
Open the application bundle and remove any unneeded "Qt Plugins" from the bundle. macdeployqt automatically compies all the Qt plugins in there, which can be kind of bulky.
Make sure you are building your application in release mode. Otherwise your application might be linked against the debug libraries of the Qt4 framework, and they are really big (for instance, well over 90 MB for the debug library vs. 16 MB of a release variant without debugging symbols). This might be what happened in your case.
If you have a large application binary, you can use UPX to compress your executable file by 40-50%.
Other than that, you should use compressed disk images to deploy your application.
One of my projects uses QtGui, QtNetwork, QtCore and QtXml and the resulting bundle is about 16 MB in size.
Hope that helps.
Unfortunately you will have to include the Qt libraries you need into your own bundle, as you cannot expect your users to have Qt installed on Mac (whereas on Linux packaging systems allow you to require at least a given version of Qt.
There is a nice tool to help you with that, which is called macdeployqt. You just need to invoke it on your bundle application and it will pack the required libraries, changing the linkage of your binary to refer to them. Without it, making bundles for Mac is a real pain (it still is, but considerably less though).
http://doc.trolltech.com/4.6/deployment-mac.html#the-mac-deployment-tool
Afterwards, you can make a .dmg image as you would do with any other app. There is an option in macdeployqt that builds a basic one.
On Linux, it's better to rely on the OS's copy of Qt, as it's almost certainly installed - for OS X, almost all apps use a statically compiled library.
Here's our problem, we are a Flex shop that uses .NET for the server side logic. We use subversion for our source control and subeclipse in Flex Builder but are still quite new to using source control let alone subversion. Branching and merging seems to work very well on the .NET side but we are running into issues on the Flex side because of the final swf being built on our local machine.
The question is, what does a usual workflow look like for working with Flex and SVN? Particularly, how do you branch and where do you build?
Personally, I keep the Flash/Flex source code in a separate SVN repository that is away from what is deployed to any sort of web server. That way I can create branches and tags specifically for my Flash/Flex application. I also tend to publish any SWF's directly into my local copy of the deployment repository. It does not make sense to me to keep a published SWF under version control unless its part of the what is deployed to the server. I don't like to keep committing an SWF into my Flash source code repository because it takes up unnecessary space and all the source code should represent the latest version, not the resulting SWF.
You'd probably want to branch your project alongside your .Net project so your flex releases are consistent with your server logic.
We use a directory structure like this
+server-side-app
--trunk
--tags
--branches
+flex-client-app
--trunk
--tags
--branches
I would recommend something like that for yourself.
I agree with Matt W. At AKQA we have svn locations four our source and assets. We set up an svn ignore for the bin folders of a project. That way we aren't checking any swfs which means when we update we don't get someone elses swfs or output files.
A good bet is to look into continuous integration with something like cruise control. We build our output on the server which generates all of the files into one location on the server. There are loads of other benefits of continous integration and it's well worth having
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.