I have files in ...bin/release where is my windows form application, I have used EEPlus library as well. What the files do I need to send to client to have application work correctly?
My files:
name.exe
name.exe.config
name.pdb
name.vshost.exe
name.vshost.exe.config
name.vshost.exe.manifest
EEPlus.dll
EEPlus.xml
I know that first two are mandatory, but what about all rest?
thanks in advance
name.exe //necessary, it is your main executable
name.exe.config //necessary, it is your application config file
name.pdb //not necessary, it contains code and debug symbols configuration of your assembly, but let it be there, it is useful when users encounter a bug or crash
name.vshost.exe //not necessary, it is the hosting process of visual studio for debugging purposes
name.vshost.exe.config //not necessary, config file of name.vshost.exe
name.vshost.exe.manifest //not necessary, manifest of name.vshost.exe
EEPlus.dll //necessary, it is one of your application dependencies
EEPlus.xml //not necessary, contains some information for EEPlus.dll
reference for xml, reference for vshost, reference for pdb
All except *.pdb and *vshost*.
Really you should look at the REFERENCES of your project.
Generically all the assemblies that don't make part of the NET Framework need to be redistributed.
In this case, it seems that you need to distribute EEPlus.dll only.
The other files are there just as a byproduct of the compilation.
Of course, you should also consider that a thirdy party library could need other files, but this should be explained in their documentation under the redistrubute page.
You could try this:
Delete all files except the name.exe, name.exe.config and EEPlus.DLL, then run your app outside VS directly in the BIN\RELEASE folder. However I recommend to have a clean virtual machine where you could test your app and be sure to not forget anything.
Always
name.exe
name.exe.config
Dependency dlls
Interop dlls
First we check this mandatory files before giving to client, because at client, when running application that will be crashed without displaying any errors...
Related
after compiling a simple console application project for release I get a lot of output:
The .exe => thats fine, I need this for sure :)
MyApp.exe.config => Im using and changing this, thats fine
Some .dll files => these are the extern libraries Im using, I think thats fine too
Unknown:
MyApp.pdb
MyApp.vshost.exe
MyApp.vshost.exe.config
MyApp.vshost.exe.manifest
log4net.xml => huh, the config for log4net is already in MyApp.exe.config, why is another log4net config xml here?
Can I delete some of them without getting later trouble? Can I add the .dll´s somehow into the .exe (so that I dont have to copy always all the .dll with the .exe)?
This is expected, and all have purposes - but you are right: you don't need any of the "unknown" files, and can delete them (and certainly don't need to distribute them). For info:
MyApp.pdb is the debug symbols; useful for stacktrace, and for debugging later if problematic; you can disable this via the Debug Info option in the Advanced Build Settings dialog (Project Properties, Build, Advanced...) but I don't recommend it
MyApp.vshost.* is the debugger host process; you can disable this by disabling the "Enable the Visual Studio hosting process" option (Project Properties, Debug)
log4net.xml is the intellisense comments - useful for IDE usage when adding references
Those files aren't meant to be distributed to client pcs nor are useful for app to work properly: they're there (also) for debugging purpose.
If you want to "merge" dlls to your project, try using Microsoft utility ILMerge.
When you build your solution in release configuration there will be no *.vshost.*., this is an executable for debug hosting process.
log4net.xml you can remove, I believe.
You should be fine deleting/not deploying most of them.
If the dll's are managed assemblies you can use IlMerge which will add the dll's into the exe for you.
Whats a good approach for white labeling dll and exe with visual studio?
In essence we want to be able to have the name of the dll and exe change based on the client that we are packaging the solution for, e.g.:
Instead of myCompany.exe and myCompany.db.dll, I would like yourComany.exe and yourComany.db.dll or acme.exe and acme.db.dll, etc
Edit:
Currently we are using a straight visual studio build process with a wix project to create an msi.
If the only justification for rebuilding it is to change the name, can you just use something generic in the first place? Imagine having to patch 50 identical DLLs, and build/deploying each one separately because they all must be named different things. Even if it's only for a few clients, I would hate to have to maintain that. Versioning could be a hassle too.
If you must do it, I would probably go with a build task (which can perform fairly advanced operations). You mention that you are "packaged the solution"; the viability of a build task would depend on how it is being packaged.
In response to your comment about naming the EXEs with client-specific names... My obvious suggestion there would be to have those applications contain as little code as possible.
The simplest build integration I can think of would be to create a post-build task which ran upon successful compilation in release mode. The task could then read a config file which defined the unique names, and copy the successfully built EXEs to an output directory.
Some of the operations can be accomplished just from the task config file: http://msdn.microsoft.com/en-us/library/ms171466.
Alternatively, you might want to create a little application to do all the work for you, and just pass config switches to it.
For example, here is a little post-build command that I execute to minify my JavaScript/CSS upon successful build of a web application. The concept is similar:
build
execute an app (like msbuild.exe, or your custom build app)
pass data to the executable (like paths, switches, etc.)
executable writes the files out
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
"$(ProjectDir)Properties\build\minify.xml"
/p:SourceLocation="$(ProjectDir)client"
/p:CssOutputFile="$(ProjectDir)client\final\final-full.css"
/p:JavaScriptOutputDirectory="$(ProjectDir)client\final"
You could use ILMerge in whatever post-build process you want on all your outputted assemblies (dll and exe), to create one-off customer-branded builds.
ilmerge /out:CustomerName.exe internalName.dll internalName.exe
I don't know that there is a good way to do this without actually building the project as XYZ company. You could try something like this which will give you the desired result BUT it will change the physical name of the assembly as well which may cause dependency problems.
I am new to C# programming and I have a problem with dll creation.
I opened a class library project and write public static methods in my classes. Clicked debug and copied dll and pdb files (under bin/debug/..) to my WPF application project.
I didn't get any reference problems also editor shows my methods normally, also when I use them it gives me no error or warning...
However, when I run my program, I saw that my methods calling dll methods are not working. In addition, debug mode also jumps my methods so I cant trace the code.
Where am I doing wrong? Is there any other way to create dll or am I missing a trick in here?
Thank you..
Rather than copying the DLLs into your WPF app's bin directory, you should either add a project reference to your class library from your WPF app, or add a reference to the output directory of the class library. Otherwise the build is probably copying over your hand-copied files. Basically, you should treat anything in bin as "controlled by Visual Studio" IMO - don't copy anything there manually. It helps if you use project references rather than referring to specific files, too - that way each build gets an appropriate configuration for its dependencies.
Since the suggested way of storing plugins in MS CRM is via the CRM database, I figured it's about time to do something about the method I'm currently using, which is storing the DLLs on the disk.
The trouble however is that I don't know how to embed all the other various bits that are needed by the DLL: the localization resource files (which are kept in another folder) and some referenced DLLs from the latest SDK (which had to be manually placed in the bin\assembly folder). At this point, I'm not even entirely sure this is possible.
So far I've tried to solve the localization problem by changing the build action on the resource files to "Content" or "Resource" and tested this solution (still keeping the location on-disk, but without the added localization folder). This didn't work: when I purposely generated a validation error in one of the plugins, I got the default language message (English) despite having a different language selected in the CRM.
I've faced a similar problem when trying to add some of the referenced DLL files (namely the new SDK DLLs: xrm.portal, xrm.portal.files and xrm.client). When I tried to store the plugin in the database (skipping for a moment the localization issue), I got a CRM error saying it cannot find the XRM.Client assembly or one of it's dependencies. I know I could use ILMerge to put the whole thing together, but I've got a gut feeling telling me this isn't really a good idea.
Any hints or suggestions on this issue would be great.
We always ILMerge our plugins and have had no issues with that. We don't merge in the SDK dlls, because those will already be GACed on the target server.
We don't really do localization inside our plugin dlls, though, so I think what you may have to do is, if your current resource manager is file based, to make it assembly based and just load up the necessary resources from that.
I have a set of helpers that are bundled in an external assembly that I use for most of my implementations. I will deploy this to the bin folder and leave it at that. I've never tried ILMerge myself, but it seems like an interesting concept.
Simply drop the DLLs in the folder CRMWeb\Bin
I have an old PowerBuilder application that we are slowly phasing out. We are also moving to a more service orientated. So in order to facilitate this we are using C# COM wrappers to call WCF methods so old direct SQL calls can be slowly removed. We also use the C# COM wrappers when need functionality is needed in the power builder application.
Since we are using COM calls to DLL from PowerBuilder to C#, there is no need for an external executable. This means that a app.config file will not be loaded on its own. At least that is what I noticed. Example: Let's say the main DLL that has the wrapper methods is Wrapper.dll. If I had config named Wrapper.dll.config it would not get loaded when the make my call from PowerBuilder to C#.
The reason I would like to use a config file is because I would like to start using log4net in the C# dlls in order to make debugging easier because it is hard enough with PowerBuilder. There are other reasons that I would like to load configuration files but the easiest to explain is basically it is easier to set up some stuff using a config file.
So is there a way to load a configuration files into the Configuration manager for a COM call?
Thanks
Tony
Check out this code from Mike Woodring. I think it will enable you to do what you want.
Nice snippet JP.
By default, Runtime assemblies actually get their config settings from the calling executable's config file. Your snippet allows the loading of one associated with the actually library assembly.
Thanks for the answers, while helpful it was not what I was looking for. The "easiest" to do what I need is to name the config file after the calling applications exe. So if the application's name is test.exe and your C# dll is wrapper.dll, then you would name the config file test.exe.config. Since test.exe in this case is a PowerBuilder application, I can get away with this for now. If it were a .net app (and probably others) it would probably already have a config and thus get in the way.
Tony.