So I have an ASP.NET VB website that references several other projects (their DLLS are just put in the site's bin folder). I need to update a small piece of code in one of the projects, which I have done and it builds fine. However, when I copy over the new DLL to the website's bin folder it fails to build, and all the Imports statements say "BC40056: Namespace or type specified in the Imports xxx doesn't contain any public member or cannot be found", which results in a ton of errors like "is not defined" . There is no reference to the updated DLL in the website project's properties, but if I put the old version back it's all fine.
The project was copied from a server and the vbproj file contained references to other DLLs, but the HintPaths were a mixture of mapped drives and ..\..\..\. I've updated these so that they're all the full server location path, but this has made no difference. I tried adding the project to the same solution as the website and added a reference to the project instead, but this also made no difference.
I've done plenty of Googling but have yet to find a solution. Any help would be very welcome!
A few things
You don't want to just "place" the .dll's in the bin folder. One big reason is that when you do a "clean" project, the bin folder is deleted. So, anytime you do a clean project, what is in the bin folder is cleaned out. And a developer will often do a clean project if some kind of problem is occuring.
I would place those files in some folder in the project. (create a folder, or if its only one or two .dll's, then place them in the root of the project). At compile time, the .dll's will be copied to the bin folder. And if you using web deployment, then you can choose to have the .dll's all combined into one .dll. So, once again, you can see it makes little sense to place the .dll's in the bin folder, since during a build, they will not be required, and as noted, the resulting bin folder can and will as a "regular" development process be re-created (emptied out). I seen a good number of projects in which the developer did place the .dll in the bin folder (because they did not know where else to place the .dll's, and that was seemly the only place that the application worked. But, during a web build + deployment to the production server, those .dll's can be left behind - they not be copied to the final "deployment" build. (I'm basic saying don't do this!!).
You can also consider just creating folder called "packages" in the root. This is where all the nuget packages are placed. So, some folder for those .dll's is the idea here.
The other big issue? Well, just dropping some .dll's in some place does NOT give you the developer all the methods and properties of those .dll's when writing code (we are assuming these are managed code - not win x32 .dll's).
So, without adding a reference to that assembly, then I can't see how the project will even compile correctly, and how syntax checking, and general use of the assembly will ever work during the development process (so VERY perplexed that you don't have references to those .dll's - that as a general rule can't work).
Now, to use the assemblies? Yes, you want to add the .dll as a reference to the project.
So, in references, add the .dll as a reference.
And then in the property sheet for the refence? Make sure you have the "copy local" set = true.
eg this:
So, above is GhostScript.net reference. (a open source library to manipulate pdf's).
Note the long path name for the .dll location. But, MOST important is the copy local setting = true. This means during a compile and build (which as noted can clean out the bin folder), then the .dll will be output to the final build in the bin folder.
So, I can't see how you can compile anything without an actual reference to the .dll. That is quite much assumed and a given - else I see no way how your project can compile under any circumstances.
So, referance the .dll, and that should allow use of the class(s) and objects, and enable your code to compile. And make sure the copy local = true, as that is the process that will copy + place the .dll in the final output (bin) folder when you compile.
So it turns out that the project for the DLL I was trying to reference had the Target CPU set to x64. Changing this this to 'AnyCPU' then allowed me to reference it.
This post gave me the answer: Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)
Related
I have an ASP.NET (4) Web App solution with 3 projects. Project A references B & C (along witha bunch of other 3rd party DLLS like Crystal Reports etc).
I have 3 build configs, Debug, Test & Release.
If I do a build in any of the configs, the built DLLS (and PDB if it is Debug) are placed as they should in their respective folders.
So Test gets built into {root}\bin\x86\Test
Release into {root}\bin\x86\Release
Debug into {root}\bin\x86\Debug
Also, all the dlls that are referenced have their 'Copy Local' property set to true and so they are copied into the {root}\bin folder so I can run and test locally in VS.
BUT
The main app DLL (ProjectA.dll) is not being copied into the {Root}\bin folder when it is being built/rebuilt, just being left in the folder for the chosen build config as described above. So when I run the app in VS I get an error 'Could not load type 'ProjectA.Global_asax'. Not surprising given the main project DLL is not in the Bin folder where the web server is looking for it.
The only way I can get it to run is to manually copy the ProjectA.dll into the {Root}\bin folder myself which seems a nonsense and obviously fraught with the risk of me forgetting to copy the latest on over after each build.
Surely there must be a way of telling VS to copy the main app dll (ProjectA.dll) as well as all the referenced dlls, into the main {Root}\bin folder?
Obviously, as ProjectA.dll is the main app assembly it is not in the list of references so I cant just set the 'Copy Local' prperty for it. Unless it is hidden away somewhere else? I have trawled every form and dialog in VS (and hours on Google!) and just cant see how to tell VS 'Please copy the main app assembly back into th bin folder when you have finished building'.
Can someone pls help ths is driving me nuts!
Many thanks
Mark
If you just want avoid the manual work of moving the dll after every build, then you can create a Visual Studio post-build event to copy the dll. Some examples here and here.
I noticed today that whenever I build a word add in project of mine, Microsoft.Sharepoint.dll is being copied into the bin folder and is subsequently included when publishing.
Is there an easy way to see why this (annoyingly large) dll is being included when publishing?
It isn't referenced directly. There are 3 dependencies in the project page and I've checked all these projects and none of them reference it directly either. Do I need to continue following the dependencies of those projects too?
Is there not some kind of log file for a build that could give me a hint?
EDIT:
The problem was that my project referenced a project that referenced a project that had a reference to Microsoft.SharePoint.dll with copy local set to true. I had to delete the dlls from all projects and rebuild with copy local set to false. I didnt realise that the 3rd party dll would be copied into my project.
If this is being pulled in due to a dependency from another DLL, then try looking at all of your DLLs in Dependency Walker. It finds all of the dependecies that a dll has. This is usually only when they are actually being used/bound, but you can also use the Fusion Log Viewer to see where all DLL binds are being bound from.
You could have a a look at reflection mechanism of asp.net or if not you could run trace using firebug for cross reference on browser ,
In our ASP.Net web project we seem to have some .refresh files associated with some of the 3rd party Dlls we're using. Any idea what they are and how/when they are created?
These files give the path to the DLL in question to tell Visual Studio where to find it (you can check this if you open them in a text editor). They will be created each time you add a new reference to the project.
They normally appear when you are using a project type that does not create a standard Visual Studio project file, as normally paths to referenced DLLs would go in there.
From here:
In an ASP.NET project, adding a file-based reference will add a .refresh file in the Bin folder. When the project is under source control, this file is then added to source control. *.dll.refresh files that litter the bin directory. Every time you add an external reference, you'll find a dll.refresh file right next to it. These dll.refresh files are an exception to the rule, and they should go into source control. Its the only way your web project will know where its references live.
Some information about the refresh files after trial and error. These experiments were done with Visual Studio 2012. The references were added to a C# asp.net web project.
As was discussed, adding a reference to an assembly through browse adds a .refresh file. However, if there are additional dependent DLL's on the explicitly added DLL in the directory that you add from, the dependents are implicitly added as well, but without .refresh files! So for example, I add a reference to "MyAssembly.dll" I will get also "MyAssembly.dll.refresh". But if there is an assembly "MyDependentAssembly.dll" that "MyAssembly.dll" depends on I will not get a "MyDependentAssembly.dll.refresh". So what happens is that the one assembly is refreshed but not its dependents! You must add the DLLs one at a time in reverse order of dependency and then things will work better.
Some other things to be careful of.
Adding "MyAssembly.dll" will also add "MyAssembly.pdb" if it is present. Also "MyAssembly.xml" will be added to the references if it is present. Those two files will refresh too when "MyAssembly.dll.refresh" is present.
But, when does Visual Studio decide to look for refresh files? Now remember, in a web project, the project file does not keep track of referenced DLL's specifically. You will not find the DLL's listed in the project file only project dependencies. So when does the refresh happen?
The answer to when refresh happens is during a build when the referenced assembly has to be loaded. That means, though that building a prebuilt updateable website may not grab all of the DLLs. I kept having a DLL that would not refresh and then I realized it was being used only inside of a .ascx file. Unchecking the "Allow precompiled site to be updateable" checkbox in the MSBuild Options project page fixed that problem for me.
Still if you add referenced DLLs that are loaded through reflection in your code, they will not be updated through a reference. You will have to use build events to copy them into the bin directory.
I have a Sitecore/ASP.NET projects that I'm developing. Today at some point I inadvertently hit the "Clean" option in the solution context menu. It took me a while to figure out why my site was hopelessly broken. Turns out Visual Studio went ahead and deleted several required assemblies from the \bin dir which are not part of my project.
How can I prevent this from happening again?
The odd thing is that it did NOT delete everything... just a small handful. It left many that are not directly referenced by my project. This makes me wonder exactly what this feature is supposed to do? Is there some sort of file flag I can set? None of the files are set to read-only. If you're interested in details, the following got deleted:
Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web.dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll
UPDATE: You know what... I guess what I'm really more interested in here is WHY Visual Studio is leaving most of the files and only deleting these specific ones.
The correct answer to your problem will depend on how you are referencing the assemblies and how you include them in your project output.
The bin and obj folders generated by a project are best considered "output" folders; these folders should only contain files produced by the project build.
When you perform a clean or rebuild of a project, all intermediary and compiled files are deleted from these folders.
You should be comfortable this is happening.
You should be able to restore these folders by running the build process at any time. If you have added files to these folders directly, it breaks the purpose of these folders and means you ought to rethink how you're adding those files.
The preferred way to reference compiled assemblies is to add them somewhere inside your source folders. From there, they can be added to a source control system as easily as any other file and can be referenced/copied by projects which depend on them. In my work, we have a "Libraries" folder which contains numerous third-party assemblies referenced by multiple projects in our solution hierarchy.
Try using a source tree like this and seeing if it works for you:
/Projects/My Solution/
/Projects/My Solution/Libraries/
/Projects/My Solution/Project A/
/Projects/My Solution/Project B/
We always add an AfterBuild event to the project file containing Sitecore.
<Target Name="AfterBuild">
<CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*">
<Output TaskParameter="Include" ItemName="FilesToArchive" />
</CreateItem>
<Copy SourceFiles="#(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" />
</Target>
Where the CreateItem Include is the path to where you have placed your Sitecore binaries.
Put the dlls in a different directory. You will probably not want them as part of the project. Reference the dlls from the new directory. When you compile the dlls will be copied to the bin directory.
I work with lots of projects and keep a bin directory at the root of my projects to store 3rd party dlls for exactly this reason.
Example directory structure:
MyProjects
- bin
- 3rdParty.dll
- Project1
- Project2
- ProjectN
This allows all the projects to have a well-known reference location for 3rd party dlls without having to copy the dll into each project.
If you are working on a team you should all agree on a standard directory structure for your code. This will save you lots of headaches beyond just this.
In case of Sitecore, just make sure to set the property of the reference(Sitecore.Kernel, Sitecore.Client, etc):
'Copy Local' = false.
I believe that if you put these files in a subdirectory other than bin, Visual Studio won't remove them. You can still make the new subdirectory part of your deployment.
Well, I'm going to go ahead and answer my own question, since it seems like the simplest answer so far. I marked the assemblies in question as Read-only. Now they don't get cleaned.
Still wondering why most of the others don't get deleted.
We're in the middle of changing from VSS to Subversion and we have a website project on our Subversion Repo. We've removed the Bin folder as it causes all kinds of chaotic tree conflicts since our development solution contains some Class Library projects the Website project depends on (set up as project references in our solution). We also have a couple of 3rd party library DLLs in the Website's Bin folder too.
The next phase of our project involves a designer modifying themes to our website. I'd like for him to be able to just open the Website project in VS 2005, modify the CSS files he needs to on his working copy, and test his files on his localhost. He'll need the most up-to-date DLL files for him to be able to do this.
Is there anyway to add the Bin folder DLLs to subversion, and configure TortoiseSVN or subversion so that we can commit our newest DLLs (project dependencies in developer's solution files) but ignore them on update (per client I guess)? It would also be handy to have our 3rd party website dependencies on Subversion too.
You should not put 3rd-party assemblies into the bin folder. In fact, you should assume that the bin folder will be emptied before each build. It is a place to put the output from a build, not a place to put inputs.
Put these binaries in to some other folder, maybe "3rdPartyAssemblies". Use a file reference to these files, and they'll be copied into the bin folder, as outputs.
Would it not be possible to structure it like this:
Trunk/
WebApp/
ClassLibrary1/
ClassLibrary2/
ClassLibrary3/
3rdPartyDlls/
build.bat
The web app is what pulls all the class libraries and the 3rd party dlls in to the WebApp's Bin folder (All of these will be referenced via relative links). You can then setup TortoiseSvn to call the build.bat file on update through client side hooks. You would also setup IIS on the designer's machine to point to the WebApp directory.
As other users have pointed out, you could use svn externals to pull in those enterprise wide class libraries.
What most everybody else has said regarding '3rdParty' is correct.
You may also consider svn:externals to pull in related directories including a '3rdParty' assemblies directory, or even output directories from builds that can be triggered by a check in to assure currency.
The approach we've taken is, rather than having the Libraries in the same solution, they have separate solutions and we (well, our Build server) compiles them and checks the compiled DLLs into sourcecontrol under "Dependencies" which is always mapped to C:\Dependencies on all developers machines. We then use file references to this folder from the website project.
Thi way you can give your designer the Website project along with a copy of C:\Dependencies and they'll be none-the-wiser =)
We don't sourcecontrol the bin-folder since it would be updated everytime you run a compile. Instead, we keep references to 3rd part libs in a separete folder that is under version control, that we have references to in our project.
With this setup and using "copy local = true", they are automatically added into bin upon compilation.
Secondly, we will only commit new binary files when we update the 3rd-part binaries.
This approach is also possible to do for your internal dlls, so that your designer can just compile his visual-studio-solution so taht any relevant dlls would be put into his bin-folder and hence, create a functional site locally on his machine.