I use the publish option of asp.net 2.0 to create a deployable copy of my web application. Lately I've noticed that the System.Web.Extensions.Design.dll and the System.Web.Extensions.dll does not get copied when using the publish option.
Has anyone any idea why this could have happened?
Couldn't google anything definite about this too...
Thanks.
They're part of the framework, so they are not published.
As others have pointed out they are part of the .NET framework and installed into the GAC which is why they aren't copied in a publish. Visual Studio expects them to be installed in the same location on the deployment target.
That said you can change this, right-click on the reference go to Properties and change the Copy Local to true. This will put a copy of the assembly in the local bin of the website and copy it when you publish.
Related
Hi guys I got some code here thats buggin me.
ive managed to create a page and get it working on local host, but when i publish this to go live and nav to the web page it comes up with this error.
Could not load file or assembly 'DevExpress.Web.v11.1,
Version=11.1.4.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a' or
one of its dependencies. The system cannot find the file specified.
(E:\web\shafteccom0\htdocs\Calendar\web.config line 44).
Ive tried adding all the references, and i mean all of the dev express ones, including ones i dont even need.
my project is a web project using visual studio 10, asp.net,C# & .Net version 3.5
ive also tried changing the .net version to 2.0, 3.0 and 4.0 but no luck.
If you need my code let me know and ill edit this.
Many thanks
That error means that the library that your application is looking for does not exist on the server you are deploying it to (or it cannot load it with the variables provided). Does the live server have the VS2010 references installed to it?
Just making sure: Are you sure your references set to "CopyLocal"?
I think DevEx installs it's assemblies in the GAC, so your local copy may be working but not when you deploy. Have you tried looking in the bin on the publish location to see if they are actually there?
I have recently upgraded my .Net 3.5 solution containing some C# code projects and a ASP.net web site project to VS2010 (from VS2008). It is building and running fine inside VS, but I get some problems when trying to build it on my server with MSBuild 4.0 via TeamCity. It seems like the projects that are referenced from the web site are not built. This was all working fine before I upgraded to VS2010, MSbuild 4.0 and Windows SDK 7.1.
Inside the msbuild script that I use to build from teamcity I have defined project references for the web site like this:
<ProjectReference Include="..\src\trunk\DataAccess\DataAccess.csproj">
<Project>{C43242F4-7286-4BEC-9A27-001D6FC14860}</Project>
<Name>DataAccess</Name>
</ProjectReference>
When I try to run the build script I get an error message saying that it could not find the dll file when trying to copy it from the bin folder of the referenced project into the bin folder of the web site. This is happening because the referenced projects are in fact never built at all (No bin folder exists in the project dir).
Does anyone have a clue what may cause this? I am not very experienced with MSbuild, so I may have overlooked some important stuff. Is it not so that MSbuild will automatically try to build the referenced projects if no project output is existing?
Will be thankful for any help!
I would need some more info to guide you on this, but off the top of my head try adding
/toolsversion:3.5
to your msbuild call.
I found another post on this website describing your exact same problem. I also ran into this same problem too.
This blog on the MSDN Website describes the problem and the work-around. Basically it's a limitation of solution files which are not in an MSBuild format, but just a fancy text file. And the real thing is, that the dependencies need to be specified in the project files them selves not the solution file. ahhh... just read the link it explains it a hundred times better than my answer here.
I have a ASP.NET project which relies upon the FreeImage .NET wrapper. This is loaded using a reference to a external directory. The wrapper relies upon the FreeImage.dll being present to work (clearly).
How do I get Visual Studio to include a reference to the FreeImage dll. It's not a .NET assembly, i think it was built in something else (so I can't add it as a reference).
I don't really want to have a copy for this project as these files reside in a different SVN repository
Add a pre-build macro/script to copy the file across each time you build. There's no way to add a symbolic link into a visstudio afaik.
I am assuming the .dll was built using a .NET supported language like C#.
You can just right click over the site and select 'Add Reference'.
Browse to the .dll you are looking for and then click 'Ok' to add it.
It should add a .refresh file to your site and the dll. The .refresh file is what is checked into your source control letting the site know the relative location of the .dll to the site.
I've got a question about something that's just been irritating me.
A colleague and I are building a support framework for our current client that we want to reference in other projects.
The DLL we want as a reference in our project would be an external reference. We're adding it by doing "Add Reference...", then browsing to the location of the .dll. What I want Visual Studio to do is only add the .xml, .pdb, and a .dll.refresh file, but instead it copies the actual .dll (and .xml and .pdb) into the bin.
When we rebuild the framework project, the other project that uses its .dll gets all out of whack until we drop and re-add the reference. Everything I've read online says that VS2008 is supposed to create the .dll.refresh files for you, but it never does.
Any ideas? Am I missing something or doing something wrong?
At this point I'm ready to add a pre-build event to simply copy the framework .dll into my bin, but the .refresh file seems like less of a hassle if it would just work.
Thanks.
UPDATE:
This SO post describes the actions that are supposed to be happening with the refresh files.
So it turns out that .refresh files are only created for Web Site projects, not Web Application projects.
The problem stems from Visual Studio having trouble deleting lock files for DLL references over 64kb, a problem supposedly fixed in VS 2010.
The current workaround is to close and reopen the solution or to unload and reload the project containing the references.
If the Projects are in the same Solution and you add a "Project Reference" that should solve your problem.
You can try to add references another way.
Add reference
Choose tab Browser (Not tab Project)
Choose *.dll that you need
I have tried it and been successful.
If you choose tab Project --> there are no *.dll.refresh added
I am working with Team Foundation Server and Visual Studio 2008 for the first time. I had a web site project that was done with Visual Web Developer Express, which I have converted to a solution containing a Web Application Project, setup for TFS source control, etc etc.
TFS was having issues checking in/uploading some of my referenced DDLs, specifically AjaxControlToolKit, saying things like /bin/AjaxControlToolKit.pdb couldn't be found. I removed the reference, deleted everything it had in /bin (it had created lots of folders like /ar, /cs, /de, etc etc along with other files like /bin/AjaxControlTookKit.dll), then re-added the reference to AjaxControlToolKit. It will now upload, and works fine locally, but it didn't re-create anything in /bin. I have other references that work fine and have info in /bin (ie: /References/LinqKit.dll and /bin/LinqKit.dll) I cannot do a build on the server yet, but locally it works. So, will this work when its built on the server? Why didn't it recreate anything in the /bin folder? Is that something to do with Visual Web Developer Web Site vs Visual Studio Web Application/Solution? Any info is appreciated! Thanks.
References are references, not copies of the assemblies. Where are the assemblies you're trying to work with?
Typically, you'll want to check in third-party assemblies that you are not maintaining source. You'll then want to change the file references to point to the version from source control.
Of course, this means that all your developers and build machines will need to maintain the same folder structure on disk.