I'm making a DLL in C# that I would like to be visible in COM without registration. Following instructions elsewhere I have generated a new "app.manifest" file in the project and edited it to include the COM information I need rather than the generic UAC information.
Except Visual Studio won't let me use it instead of the default manifest. When I open the project's properties, the manifest dropdown is disabled:
What do I need to do to select & embed the custom manifest I've added to the project?
Edit: The "app.manifest" file is in the project's Properties folder. As described here, for registration-free COM I need to change the Manifest from embedding a default manifest to using the manifest in Properties. Except it won't let me change that setting for some reason.
Edit 2: The Manifest dropdown is enabled when I change the output type to Console Application or to Windows Application. Why would it be disabled for a class library when MSDN explicitly states that a manifest is needed for registration-free COM libraries?
Class libraries don't need to use that dropdown to embed a manifest.
Important Note: Pretty much the only reason you would embed a manifest into a C# library this way is to make it available for use via registration-free COM. If you're not doing that, you don't need a manifest and these steps are not for you. Go away.
If you use Add -> New Item -> Application Manifest File to add an app.manifest file to the project:
...and keep it in the project root (not in Properties, or any other subfolder):
...it will automatically be embedded into the DLL.
You can verify that it was automatically added by using File -> Open -> File to open the DLL once it's built and confirming that it includes something called RT_MANIFEST:
Special thanks to Hans Passant for providing all this information, albeit spread around half a dozen answers to different questions rather than all in one place.
Related
My apologies for this very basic question that has assuredly been asked and answered before, also for my very dated terminology. I searched for an answer, but failed to find anything helpful. I am using the latest update of VS 2017 Community, and I'm trying to manually add what I used to call a "function library" to a project, which sits under a "solution".
The project is simply a C++ or C# console application. What I have is a .h (header) file, a .lib (static library) file, and a .dll (dynamic library) file. I intend to make "function calls" to this library. I'm aware that I need to have my dll in the debug folder where the executable resides, but I'm not sure how to "add dependencies" in VS 2017. I know how to manage and install NuGet packages, but these files aren't a handy-dandy NuGet package.
I hope to get advice on doing this the right (VS 2017) way.
What I do in a situation like this is to create a folder, I use C:\Etc\SDKs\<name_of_library> and then within that folder create an include subfolder, and a lib subfolder. Note that the top level folder choice is completely arbitrary, place it where it makes the most sense to you.
In the C/C++ section of project properties on the General tab, or the corresponding section for C# projects, there's an entry for Additional include directories. Add the path to your newly created include folder there. That'll let you include the header file and have it work right.
In the Linker section of project properties, also on its General tab, there's a corresponding entry for Additional library directories. Add the path to your lib folder there. On the next tab down: Input there's an entry for Additional Dependencies. Add the actual name of the library file there.
Those steps should allow your project to be built using the .h, .lib and .dll files you have.
-- Edit to address comments --
The .lib file does go in the ...\lib folder, and the .h file in the ...\include, that's correct. However, you had the location of the .dll correct in your original question. That needs to be somewhere on the search path that the executable will find, so the easiest place is the same folder as the executable.
General tab is a poor choice of words on my part. General section might have been better here. When looking at the project properties, the left most pane is a tree view of the various property sections. With everything closed up, except the very top item open, you'll see
Configuration Properties
General
Debugging
VC Directories
> C/C++
> Linker
...
If you then double click on C/C++ it'll open up, and show the sections specific to the C/C++ compiler:
Configuration Properties
General
Debugging
VC Directories
V C/C++
General <<<<<
Optimization
Preprocessor
...
> Linker
...
If you click on the word `General that I've highlighted, that'll get you to the General section / tab I was talking about.
Likewise, double clicking the word Linker will open up that section, and under that you'll find the Linker General and Input sections.
Let me know if this still isn't clear, and I'll try to clarify.
My understanding (which may well be faulty) is that it is easy to set the OriginalFilename property for a C++ DLL or EXE by including a VERSIONINFO resource file in the Visual Studio build.
But I can't find any way of setting OriginalFilename for a C# build. It is apparently always set to the name of the output file being built.
I'd really like to be able to specify this if possible. Any ideas? Thanks.
OK, no answers, and now I've found a workaround.
This article here at StackOverflow was very helpful:
How do I set the version information for an existing .exe, .dll?
Which led me to this resource manipulation project written in C#:
http://resourcelib.codeplex.com/
So what I'm going to do is to modify the DLLs after they've been built.
Edit (March 2015): This is an old posting, but I can see there is still some interest in it. The "ResourceLib C# File Resource Management Library" open source project has moved since four years ago, and is now here: https://github.com/dblock/resourcelib
Yes it is possible to set it,
-> right-click on the project or assembly name in visual studio -> select properties -> select Application tab -> change the assembly name as you want.
Please refer the link to view property window, in which assembly name option is there
After changing the name compile the project,(to verify the change) right click your compiled DLL file and select properties and click on 'Details' tab, in which you can see the 'original filename' is now changed.
Sadly, no.
You can read what it is with System.Diagnostics.FileVersionInfo.OriginalFilename, but the value is filled by the Project / Output Filename not from any Assembly Attribute.
Running your patch program to change it after a build runs the risk of breaking any digital signature applied during the build. You may need to build without signing, patch the attributes, then sign it in a separate step.
I've got an C# Project in Visual Studio, which has Console Application as Output Type.
But I also need a Class Library of this project for another solution.
Right now I have to switch the output type every time, but I wonder if it's possible to generate exe and dll at the same build-event?
Is there a post-build-event for this?
To my knowledge there is no possibility to change the output type after compilation. That being said, if would be possible to have two projects like Console and Library in your solution, which would use the same source code files but have different output types. That way you would have different outputs without any duplication of code.
it is generally possible to reference a .net exe assembly as it would be a class-library.
So you can just stick in creating an exe file and reference the exe (sounds strange, but works) in your other project.
This is the dialog for browsing for references. As you see you can select exe files.
But as commented it really depends on what your usecase is.
I don't recommend to ship an exe with an entry point to your customer hoping that the customer does not discover the exe. But what you could do about that is to conditionaly compile your entry point.
For example
class Program {
// This is the entry point of the EXE
public static void Main() {
#if DEBUG
// Start Debug Application
...
#else
// Shipped to client - Entry point disabled
return;
#endif
}
}
If there is a relevant reason to have a shipped exe and a shipped class library, I would refactor your solution like this:
(A) complete application (.sln)
(B) console-application (.csproj) which has a reference to (C)
(C) class library project (.csproj)
With that it is perfectly clear to others that there is an application that uses the library and the library itself.
Console Application is the type of your project. You can not change it.
What you can -and must- do is, carry your logic into a Class Library project and use your class library from any type of project you want.
You should compile your project to become a dll and then use this dll in a console application.
A possibility to achieve what you want is to manually run the msbuild on your post-build event of your project.
See: How do i build a solution programatically in C#?
or Building C# Solution in Release mode using MsBuild.exe
The usual solution for this is using a Solution with two projects:
a Class Library with all the code (which builds into a DLL)
an Console Application referencing the library whose Main just calls some function(s).
For more information, check the MSDN page on Solutions.
Codor suggested manually adding the files to the Console project, but one downside is that build settings are not shared between both versions, so you might get some inconsistency there.
I'm not really sure why people think it's not possible but it actually is.
The easiest way would be renaming the exe to dll Sounds stupid, I know. But it works in many cases. Also, as "Peter I" said a .NET exe can be imported as assembly in other projects. So you might not actually need a dll anyways.
Another way would be using C# command line as stated here: /out (C# Compiler Options)
You can use command command line options in Pre/Post build events Pre-build Event/Post-build Event Command Line Dialog Box
I have a similar requirement and couldn't find any definite answer in this post or anywhere. I currently have a class library and would like to create a console application project without copying any code. Ideally speaking there should be two projects, one for creating a console application and another for creating a class library. And this is what the visual studio also suggests. When I tried to run the class library, I got the below message.
It clearly asks us to add an executable project to the solution and add the reference to the library project.
Below are the steps to do this.
Right click solution -> Add new project -> Console App -> choose name -> ok.
Right click on the console project -> add reference -> In reference manager, click on the projects tab and select the other project(In my case this is the class library project, In case it is not listed just click on browse and select the .csproj file) -> ok.
Now to use the classes in the other project, simple do using LibraryProjectNameSpace
There we are. Bingo!!!!
Also as mentioned in the other answers it is not possible to have the same project generate both .exe and .dll. But you can have the same solution generate these two guys by having two projects. In this way there is no need to switch the output of the project every time.
FYI, I use visual studio 2017
I have multiple projects that are accessing the same settings (they were a single project, but I'm re-factoring). What I would like to do is the equivalent of:
"Add Existing Item" -> "Add Link"
The projects are a mixtutre of both C# and VB. When I try to do add as link, it does bring the settings file in, but it doesn't recognise it. I actually get the error when trying to load the settings:
Error HRESULT E_FAIL has been returned from a call to a COM component.
Is there a way to tell the project to use a specific settings file (either inside or outside the IDE)?
I usually put these things in a common library. When sharing settings, you probably share more than just that, so combine it then. When marking the settings as public instead of internal, you can access them across the other projects.
For future reference:
The solution was to add the Settings file 'as link' to the project, right click and hit 'Run Custom Tool' where the Custom Tool property of the Settings file is 'SettingsSingleFileGenerator'.
Note that this solution is not favored, since it depends on manually updating the settings designer file by performing the above actions.
Taken from MSDN: Add Multiple Settings
"In Solution Explorer, drag the new Settings file into the Properties folder. This allows your new settings to be available in code.
Add and use settings in this file as you would any other settings file. You can access this group of settings via the Properties.Settings object."
I have done this,and it works for me in my C#/VB mixed projects. Hope this helps
I'm working in a solution with ~100 project (of mixed C# Winforms, VC++ Winforms, and Unmanaged C).
I have a project, named 'DatafiltersControls' (C#), which has a references to a project named 'DatafiltersTypes' (VC++), shown below is the xml entry for the specific reference.
<ProjectReference Include="..\DatafiltersTypes\DatafiltersTypes.vcxproj">
<Project>{360679FF-815C-4B39-8E5A-62C0D2A6DB31}</Project>
<Name>DatafiltersTypes</Name>
<Private>False</Private>
</ProjectReference>
Now, the problem: "The designer will only load my controls under certain circumstances". After doing a lot of research, i've broken it down to my development environment, and the way I open my solution. My build environment is created from inside a dos window, which will subst a new drive (P:), mapped to a directory.
After my directory is created:
If my prompt is has "p:\common" as the current working directory, and type common.sln, all designers work great with no issue. This was the current working directory when I initially set that reference in the first place.
If I doubleclick on common.sln from explorer, and then try to open a 'complicated' form, I get the following error: Could not load file or assembly 'DatafiltersTypes, Version=1.0.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified
If my prompt has "p:\" or any other directory as the CWD, and then invoke "p:\common\common.sln", the designer breaks on complex forms (same as above)
I believe the specific problem is this: my references where added relatively, based on the CWD when visual studio was opened. From that point on, the designer breaks on any 'complicated' form, because the search path is based on the cwd.
If needed, I can define 'complicated', I have the exact circumstances. My ideal solution would to allow my references to be based on the root of the drive (its a constraint developers at my company already have anyways). For instance, instead of
....\build\output\datafilterstypes.dll, I want \build\output\datafilterstypes.dll as my reference.
Its important to note that: Everything compiles just fine regardless of my working directory when I load devenv, its just the designer.
Thanks in advance.
Edit: To add, I have the same issues if the
The problem is the designer cannot load C++ dll's that aren't pure. Convert any project that will directly, or indirectly, a C++ dll to be pure.