I used to add my ASP.NET dependencies added as a 'Reference' in my project, and also added them manually to the '/bin' folder. This seemed a bit redundant, as so I removed everything from the bin folder. The project compiled and runs, but VS2010 started to act funny now. It doesn't recognized a lot of my controls (eg. Telerik UI) and therefore a lot of HTML is underlined as an error. So is this because I really need to add my files as both dependencies and into /bin, or a different problem?
Try to make a complete rebuild for your sollution.
Select properties on the referenced assemblies and check "copy local". This will copy the files to the /bin folder on compile.
Assemblies installed in the GAC will not need to be copied to the bin folder though. If you plan to deploy your solution to another machine, consider what assemblies are on your development machines GAC but not on the live/deployed server (and then either install them to the GAC on the live server or have vs copy to the bin by selecting copy local)
Related
I would like to have a smooth and efficient installation of the solution, but what I "inherited" is very far from that, and the guy who programmed most of it has left the company.
At present I am trying to install it on a test-server, and not all the dll's land in the correct places after the installation.
Firstly, if I use log4net in a project, then I need the log4net.dll in the folder after the installation (I guess). How do I get the log4net.dll to be copied with the project dll?
Secondly, Project A expects Project C's dll to be in the GAC or so it seems when I debug in Visual Studio and check where the modules are loaded from.
I also see that this is entered in the post build event commandline of Project A:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\GacUtil.exe" -i "$(TargetPath)"
copy "$(TargetPath)" "C:\Program Files\MySolution\bin"
So how do I get Project C's dll into the GAC by way of the installation? I get an error on the Test Server because it can't load C.dll.
UPDATE WITH MORE DETAIL
After the solution has been installed with Windows Installer, a few folders are created in the parent folder such as Apps, bin, Engines, Service etc.
In the Apps folder, I have A.exe, which is looking for C.dll. However, C.dll lands up in the bin folder. As mentioned above, during execution of A.exe, it actually loads the modules of C.dll from the GAC (and on my laptop, those files are in the GAC because of the post-build event command line specified in the properties of Project C, but not in the GAC of the Test Server to which I am trying to install this solution).
So yes, I assume I could run something like this:
gacutil -i C.dll
after the installation, but it doesn't seem right.
There are two parts to your question relating to the GAC, and ensuring DLLs are copied.
GAC
Check out this link (https://msdn.microsoft.com/en-us/library/dkkx7f79%28v=vs.110%29.aspx) from MSDN on how to install into the GAC. The key thing is it must be strongly named or it will fail.
DDLs
Depending on how you are referencing Log4Net, there are a few ways to do this.
If you can add a reference in your project, make sure the property CopyLocal is set to true
If you just have the file locally, you can add it to a sub folder of your project with a symbolic link (https://support.microsoft.com/en-us/kb/306234), and then set the CopyToOutputDirectory property.
Hopefully these help you along.
I found what I was looking for!
Select the Setup project, then go to the menu "View" -> Editor -> File System.
It seems you can specify where the dlls must go, and what should be copied to the GAC during installation.
I have 3 projects in my solution and a bunch of 3rd party or company dlls. Each time I rebuild my project or clean solution, a lot of this dll's are deleted, therefore missing. It is pretty annoying to reference this dll files again and again after rebuilding. Can someone explain how to avoid this? Thanks in advance.
The bin folder is just the binary output from a build, so when you clean your solution, all the assemblies in the bin folder get deleted. You should reference the assemblies from some other location. One suggestion is to create a Shared Resources folder within your project, copy your assemblies to that folder, then reference them from that folder. This way they won't get deleted from bin on a clean/rebuild and Visual Studio will copy them there as needed.
Right-click on the References folder in your project and choose Add Reference...
Use the browse functionality to locate the assemblies you want to reference (don't worry about manually copying them to/from your bin folder)
After the reference is added, right-click on the reference in your references list and choose Properties
Make sure the Copy Local property is set to True
This will ensure that assembly is copied to your bin folder on every build.
In my case, .net framework version is the problem. I had to lower its version to 4.5 and then the projects got built properly and able to reference in other projects
As Troy explained in his answer, indeed a reference to a *.dll file, kept outside the bin folder, ensures that the dll file does not get definitively wiped out when cleanning the project.
However, just by adding a reference to the assembly might not be enough. For instance it would not work for some other file types, such as the *.pdb files as well as for the *.resources.dll files (which are typically spread in many sub-folders named after the language codes (2 letters' language code)
To depict this problem with a real life situation, I picked up an assembly for which the source code is either gone, or not compatible anymore, etc. I chose (on purpose...) a 13 years old AjaxControlToolkit composed of many component files. The picture below illustrate its composition. Every time the "Clean" command is applied to the project all these files are deleted, except the one which is the referenced assembly. Moreover having several *.resources.dll file assemblies of the same name, as in the present case, makes it inconvenient, if not possible, to add "references" to each of them from within the same project.
Nevertheless here is a pretty simple workaround:
keep this file hierarchy in a separate folder (as Troy explained in his answer)
just copy them over in the bin folder using a command line entered in the Pre-build event of the project, such as xcopy "$(SolutionDir)AjaxControlToolkit" "$(TargetDir)" /y /i /s /r /q
Hoping that will be useful to someone...
I have created a build task in vs2012.
I ran it.
It complains that there are some missing references,
though I see them on my proj and they lead to relative path
(the folder that exists in the source control)
I have ereased the sln locally,
I did get latest from the source control and rebuilt it.
The references were missing. I have fixed it. Re-run the taks and again similar error.
How can it be if the sln builds successfuly on my machine and on a colleage clean machine?
If I had to take a guess, it would be one of the following:
The missing types are located in one or more assemblies that are either not checked into source control; or
Those assemblies are referenced via a path reference that isn't the right path in your source control.
Those assemblies aren't part of the normal project structure that would be pulled down by the build server.
Those assemblies are gac'd locally and you are referring to gac'd versions instead of the correct ones.
It's a web site project and someone on your team has those assemblies gac'd or installed in some other directory and they screw up the project every time they check it in. (common in web site projects, highly unusual in web application projects).
I have a c# solution with some projects. For the solution I have created a folder for extenal libs. I have copied some Telerik-dll's from the instalation to the libs folder.
Now my problem:
When I add the dll's to the projectes (I choose the copied dll's from the libs folder) Visual Studio takes always the dll's of the installation source and not the dll's of my libs folder.
How can I fix this? I'm afraid that my colleagues could not compile the solution because the dll's are referenced to a missing directory (would happen if they don't have installed the correct Telerik version).
Thanks
Edit:
For example:
I reference with the file chooser
"C:\vendors\Libs\Telerik.Windows.Controls.Input.dll"
Visual Studio references
"C:\Program Files (x86)\Telerik\RadControls for Silverlight Q2 2011\Binaries\Silverlight\Telerik.Windows.Controls.Input.dll"
Properties of the references - set Embed Interop Type to false and set Copy Local to true
during development of our application we use a branching structure and while we are developing another team is using earlier builds of our software to create content with it.
To facilitate easy swapping between builds and teams I was hoping to use empty Hintpaths in the content projects' csproj files so that they can use our GAC installed assemblies to build against and in the meantime add a reference path to the projects for our use during development and test cycles where we don't want any assemblies installed in the GAC.
However, it seems reference paths are not stored in the csproj file and thus don't get sourcecontrolled. Since there will be extensive branching it would be less than ideal to have to set all reference paths again when a developer pulls another branch from sourcecontrol.
I've been searching for a bit now and can't seem to find ways to do this. Anybody know of a way to force the reference path in and out of sourcecontrol?
We're talking Visual Studio 2008 and TFS 2008 here.
Cheers,
Anton.
Ok, I seem to be a little clearer in the head after a good night's sleep, took the logical step, namely investigate where exactly the information was stored and how. It turned out the information was stored in the .user file for the project in the project's folder and as it turens out this file contains mbsuild xml.
I then did what I wanted as follows:
Create the Reference path as I required it to facilitate both scenarios without any work.
Browse to the Project's .user file
Copy the PropertyGroup containing the ReferencePath
Paste the PropertyGroup in all the necessary Projects' .csproj xml.
Reload and build.
Done.
The references are stored in the *.csproj file. The nodes are ItemGroup/Reference...
Thomas
This is pretty simple--we do this in our shop.
First, in the Workspace (using Windows Explorer, browse to the Solution folder), create a folder. We name it "Referenced Assemblies". In here, drop all your DLLs.
Now, in the Solution, add a new folder to match the one created in Windows Explorer. Into that folder, add all the DLLs you just dropped in.
Finally, in each project, set up your references to use the DLLs that were added to the solution.
Now your project references DLLs that are part of the solution, so that when the build runs, it will grab the DLL from Source Control to generate the build.
Also, I'd recommend not using the GAC at all if you can avoid it. In my experience, reference behavior is strange. It seems references go first to the GAC, then to the DLL in the local folder, meaning that if the DLL is updated, the one in the GAC is used instead of the DLL in the local folder (which is likely the updated one).