I am trying to build my setup using the installshield software as in VS2012, you must use it. I have managed to prepare but I have one problem which is these warnings:
Warning 5 -6248: Could not find dependent file u2dmapi.dll, or one of its dependencies of component Aamali_New.Primary_output ISEXP : warning : -6248: Could not find dependent file u2dmapi.dll, or one of its dependencies of component Aamali_New.Primary_output
Actually it looks for this file u2dmapi.dll!! I have managed to download the file from internet but I do not know where to put the file so the builder would find it. I have tried to put it in several location in the project but it could not see it. Can you please help me about the location so it will get it and will not create this warning again. Waiting for your kind reply.
Thanks.
According to this article, you have to place the DLL "in the same location as the key file for the Component specified in the warning." In my case, it was a project output, so I had to put my DLLs in that project's bin folder alongside of the exe (bin\release).
There are many ways to do this:
If it's a managed DLL, add it as a reference in the project. It won't allow you to if it's unmanaged.
If it's not, you must manually copy them wherever they are needed
Or automatically by adding a Post-Build Event Command Line (project properties, build events tab) like so:
copy "$(ProjectDir)lib\$(PlatformName)\Unmanaged\*" "$(TargetDir)"
Where $(...) are predefined macros. Check them out, there are many others.
It's a bit tricky and error prone... I would've prefered a way to just flag the file as a dependency in the project but I didn't find a way of doing that.
Related
I am building a few different C# libraries that both depend on a single C# file we'll call Dep.cs, and these dll's need to be used together in a Unity project. I'd like to set up these projects in the following way:
The C# libraries can be built independently of one another using Visual Studio
C# libraries (i.e. dll's) can be imported into a Unity project without conflicting symbols
The C# library projects (i.e. the source code for each library via git submodule for example) can be imported into a Unity project without conflicting sources.
I've solved (1) by including Dep.cs in each library project that requires it, though this causes issue with (2). And I've solved (3) by putting the dependency in a folder like Dependencies~ so that Unity ignores the file (this way no duplicate classes are found).
I'm having trouble solving (2) however. I thought I'd be able to add Dep.cs as reference in the VS solution but This doesn't seem to work. I've heard of Assembly References but I am not sure if they do what I need.
You can use "Add File as Link" from Visual Studio "Add Existing File" screen. It also works well with git submodule, just place Dep.cs anywhere in a parent folder or in the solution's root directory.
To get the same result you can also directly edit the .csproj file and add a compile instruction:
<ItemGroup>
<Compile Include="..\..\Path\To\YourFile.cs" Link="YourFile.cs" />
</ItemGroup>
This method solves all the issues you mentioned.
To solve my problem I decided to modify the external scripts to be internal this way both dll's can compile with that source and not conflict with one another. The rest of the setup in my question remained the same so this solved (2) for me without compromising (1) and (3).
I have multiple projects (lets call one MyLibrary) in Visual Studio that contains a lot of nifty functions and classes I use in my other projects. I add a reference to MyLibrary.dll directly and not the project itself.
However, I now need to breakpoint my way through something in MyLibrary while I run one of my other projects. How can I debug my dll the way I've set up my projects? I know for a fact I've done it earlier with these projects, but since I didn't do anything special, I don't know what's missing.
I've turned off Just-my-code and followed some tips like that, but I haven't gotten into .pdb's yet. If I need one to debug another DLL, I would appreciate some information on how to export that from MyLibrary.
While debugging, check in Debug/Modules, if your dll symbols are loaded. If not, let them load. You may be asked to set the folder with pdb files. Pdb contains the symbol used for debugging. It has to be the same version as dll file you are using in your projects. After that you will be able to debug the library.
You might need to go to the properties of a DLL, and ensure that Copy Local is set to True. Otherwise, Modules won't be able to find the .pdb for your reference
If that doesn't help you can try to rebuild your external library using debug mode, then copy manually both .dll and the .pdb file to the bin of your app.
I was given a project in which I am supposed to debug a problem in a Windows Forms application. I found where the problem is located but it is within a Class Library which is included as a component of my Windows Forms application solution.
How can I add/modify code in the Class Library project and actually run it live so that I can debug it? If I make any changes to the Class Library as is, the application ignores the changes and resorts to the original source code.
The only things contained in the Class Library's folder are plain source code files, some settings files, and a .vbproj. I just want to make changes to the Class Library and actually be able to debug them. If anyone could please explain what I have to do, it would be greatly appreciated!
Your application is not loading the assembly produced by compiling the class library. It is loading another copy from somewhere.
One quick way to find out where is to start the application from Visual Studio, break into the debugger and then bring up the Modules windows (Debug>Windows>Modules). Look for the class library in the Name column and check the Path.
If it is under C:\Windows\Microsoft.NET\assembly... then there is an older version being loading from the GAC. If it's another location, you will need to ensure the class library project output is going to that location.
Does the startup project have a project reference to the class library in the solution? You could always remove and re-add the reference to the class library in the startup application project and ensure you add it as a project reference.
Be careful though, there may be a good reason why this wasn't the case originally.
EDIT
A full explanation of how assemblies are located is way beyond the scope of an SO post - you'll need to study How the Runtime Locates Assemblies.
With no changes made to typical solution defaults, a library is most likely to be loaded from the same folder where the start-up executable is located. Setting a project reference to a library causes it to be compiled and copied to that project's bin folder - so make sure the startup project has a project reference to your class library project. (Right-click startup project and check Add References... dialog. The reference should come from the Solution section).
You'll need to examine the project property pages to see if something special has been configured.
99.99% of the time, building the WHOLE solution and hitting run should work. If it doesn't work, something is messed up in the solution and/or there is some kind of custom deployment set up.
There are simply so many ways to deviate from the default deployment that I just can't give specific guidance here; you best bet is to get someone knowledgeable who can take a look in person, or to whom you can send the source for inspection.
I just went to Project Properties ....Project Dependencies and checked(ticked ) the class /assembly(.dll) name... It worked for me. Now i dont need to run the class project for the changes to reflect in the Startup Project ..
I've started an open source MVC4 project that is using some other open source project as a dependency. I've forked the other project and will be modifying it according to my needs. The problem I'm facing is how to keep these projects depending on each other, but maintained separately. Yet people who git pull my project, would get the dependency project as well?
I can slam all the related code from other project into my repository, but this way I won't be able to contribute to a fork of dependent project. I'll just become a part of my repository. Not really want to do that.
I can maintain other project completely separately and copy *.dll files into my project. And commit dependent dll files into git. This is nice, but I loose ability to develop two projects at the same time, along with stepping into dependent code on debug (well, maybe not if copy *.pdb files along)
Similar to point 2, I can build nuget packages from dependent project and add them to my main project - again, can't really develop both projects at the same time, need to switch contexts.
With some magic have a solution file that combines projects from my repository and from dependent repository. On every build, copy dependent dll files to /lib folder and commit them. This way I don't need to switch contexts between separate projects. But the drawback is when other contributors git pull my project, they don't get dependent project, and solution files will likely be broken for them, because it'll reference project that is not in the repo.
How do you organise your code in this case?
Usually I use nuget for all my dependencies. When I fork a project I will deploy it on nuget and also on symbol source. In this way you can step inside the dependency source without problems.
For more information on symbol source and nuget see also:
Creating and Publishing a Symbol Package.
To enable symbol source debug see http://www.symbolsource.org/Public/Home/VisualStudio.
You must also remember to enable Nuget package restore.
With this solution you can't modify source code but at least you can debug it.
I use something similar in concept to CMake, but entirely within Visual Studio. There's the relatively unknown feature of property files, which can be included by solutions. This allows you to create a file containing only paths to dependencies, include the libraries you can and set relative paths, and then require people to set the appropriate paths for the other dependencies you can't/don't want to include.
With a little bit of work, it comes out fairly clean, and is super easy to automate through TeamCity and other similar tools (each build agent can set the variables to indicate where it keeps dependencies).
For small dependencies and ones that have been tweaked to work with my project, I keep an archive or the loose files in the repository, and use the properties file to reference those. Others have instructions on where to find them and how to edit the paths.
If you're interested in such an approach, I can go into some more detail. It took a bit of work to figure out, as property files aren't super well documented, but is working pretty neatly.
In case you are not creating circular dependencies, following is an idea:
add a new Class Library project with a unique name, say ClassLibrary1, to the solution
in the Build page of its project settings, config Output path to application output path
in the Build Events page, add the following line to Post-build event command line block:
del "$(TargetPath)"
repeat step 1 to 3 but giving another name, say ClassLibrary2, and config Output path to the source path of ClassLibrary1
set Project Dependancies of ClassLibrary1, check on ClassLibrary2
add all other project as project reference to ClassLibrary2, leave Copy Local with default value true
build ClassLibrary2 once, and all DLLs now are in the source path of ClassLibrary1
add them to references of ClassLibrary1 and leave Copy Local with default value true
set Project Dependancies of application and all other projects which are not cause circular dependencies, check on ClassLibrary1
add references of other projects, from the path the DLLs were put in ClassLibrary1
set Copy Local of all these added DLLs in other projects to false
Thus, the project ClassLibrary1 be a central control of the external libraries of your solution. Each time you Rebuild Solution(or just build the application), ClassLibrary1 copies the latest DLLs add to its references to the application output folder, and deletes the DLL it generated itself named ClassLibrary1.DLL. The application and dependencies at either compile time or runtime would use the same version of DLLs, you don't need to do extra deploying or check each deployments.
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.