I have added reference to few dlls in my VB.net Project. When I check into Visual source safe and get latest version from another machine, VS.net 2008 throws errors.
I have to add the references again in that new machine. Is there anyway where I can keep the references in spite of files checked in to VSS?
I need to send copy all the files to production server and we don't have VS.net on the production box to add reference and build the application.
Thanks
First, be sure that the project file is checked in properly. Sometimes VS fails to regognize that the project file has changed.
A good practice is to check in all the assemblies that your project references, except the standard .NET libraries.
Another recommendation is to set up a build server, which will detect these kinds of problems early. My personal favourite is TeamCity.
For references that are not in the GAC, and if they are third party things that aren't built elsewhere inhouse, a simple approach is to add the referenced assembly as a solution item (Right click on solution node | Add Existing Item). I usually put solution items in the same folder as the sln and then add the reference to that location.
When you check in the solution solution items will go into source control with it.
Use this for small relatively simple applications. If you have more than a handful of referenced solution items follow #Petter's advice and set up a build server with associated configuration management devoted to third party dependencies etc. etc.
Related
I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
So I have a Visual Studio solution which contains 3 database (.dbproj) projects. These projects need to reference other sql projects from other solutions, which I have packaged and uploaded to nuget. How can I manage these external packages / references in Visual Studio within the dbproj's?
Right clicking the database project within visual studio doesn't give me the "Manage NuGet Packages..." option.
I can Manage NuGet Packages for Solution to at least download the required packages to the solution root but at the project level, where the references are required I'd have to manually manage the references within each projects' references and update manually any time the package is updated so the reference points to the correct versioned package directory.
Is there a better way to do this for dbproj references for database projects in Visual Studio??
I ended up following the same path, creating NuGet packages of the referenced databases and then manually (via command line) installing them at the standard \package location. Then correcting the database references manually in the IDE
There is a work item for this functionality, go vote it up. There is a fork of the functionality already developed that sounds like it is fairly feature complete. You might try it out.
In our environment, we have two in-house frameworks and a separate website. During development, the references to the in-house frameworks tend to be set tp project references. However, once we move to release, the in-house frameworks are installed into the GAC as they are used for multiple instances of the website on each server. All of the ProjectReferences are changed, by hand, to References and the website assemblies and website are re-compiled and deployed.
I am attempting to automate this process. What is the best way to handle these issues? I have started to learn MsBuild in the attempt to accomplish this, but am totally confused. Any pointers and/or suggestions on how to proceed?
As far as I am aware there shouldn't be any need to change from using project references to file references simply because the assembly is registered in the GAC - as long as the referenced project is strongly typed at the point that it is built, the reference should still be valid.
Clarification:
There is no fundamental difference between a GAC reference and a file reference - if you have a reference to a strongly named assembly, and that assembly is placed in the GAC then the end application will load that assembly from the GAC.
See this link for more information on how the runtime locates referenced assemblies:
http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx
FYI - I believe it is recommended that you don't reference assemblies which are in physically in the GAC, and that you instead reference the strongly named assembly before it is placed in the GAC (not to be confused with whether or not the assembly should be installed to the GAC on the end-user machine)
If you leave the project references in, MSBUILD will copy all the project references as DLLs into the target website's bin directory, even though you've installed these DLLs into the GAC, which I assume is why you want to change this at the release level--so that space can be saved.
I also assume that you are intending to do this at the Release Branch only, and not at the development branch of your source control. Because if you are doing this at all branches of source control, then doing by hand is actually the best and fastest way of doing this for a one-time change.
To do this in MSBUILD, you will need to create a custom task that can modify the project file. The project file is an XML file, so you could use XPath as your custom task in MSBUILD. In the project file, you will find tags for "" to your referenced projects. You will need to change those to "" tags instead. Use existing examples of the tag in your project to see how it should look
Sorry I don't have sample code for this--doing it this way will be a bit of an undertaking, as there will be a number of things to take into consideration, and it might end up not being feasible.
What do you do when you break compatibility on a common library used by many other libraries on your development machine?
What I usually do is:
For every dll that reference the broken one
Checkout dll
Checkout vbp project
Open vpb project with VB6 Ide
Click on References button
Uncheck MISSING reference and OK
Click on References button
Check references and OK
Click on Make dll
Close project
This can be a pita activity, when you have many Dll to recompile and it can be error prone because you could miss some Dll.
I think this problem is more related to development machine; on our staging/production server we have build tools that fix the MISSING problem automatically.
What's your best practice to handle this common scenario on your local machine?
The Way We Work -- section Handle broken references is almost the way we work.
Here is a link to the tool by LJ Johnson -- Take Control of Your Build Cycle. We are using a custom build tools in our daily builds that reads separate REF files.
If you open the vbp with notepad then you should be able to update the reference without actually opening the project. Obviously you'll need to make sure you give it the correct CLSID.
I have a project I made in Visual Basic 2008 Express. I converted it from someone else's C# project, but it works. It has several DLL dependencies. I went to publish my project so I can install it on another machine and for each DLL, I get an error: "Assembly must be strong signed in order to be marked as a prerequisite." I've done some research, but am not finding a lot and what I have found I don't really understand. What does this error mean? What is the best way to resolve it? One other thing: it took me a LONG time to be able to get all my dll's to reference correctly, so I prefer that the solution has NOTHING to do with moving DLL's around because that will likely break the functionality in my main project.
If you're publishing via ClickOnce, go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".
What this error message means is that the current publishing settings are going to expect all of the assemblies in question to be present in the Global Assembly Cache on the target machine before installation can take place. Since all assemblies in the GAC must be strong signed, any assembly marked as a prerequisite that isn't strong signed will give you this error.
The workaround is more simple than that:
Go to your project.
Right click and Select Properties.
Go to the Security Tab.
Uncheck Enable ClickOnce security Settings.
Unless you are deploying this application through ClickOnce, you don't need to StrongName your assemblies.
Strongly named assemblies are mainly assemblies which have are signed by a cryptographic key. This is fairly easy to do with Visual Studio and does not require re-ordering of your dependencies.
I'm using non-express Visual Studio so the steps may be slightly different for you.
Right click on the project and select properties
Click on the Signing tab
Check "Sign the assembly"
In the combo box select "<New...>"
Complete the wizard
Rebuild
Check this link out...it has instructions for signing your assembly with a strong name:
MSDN: Signing an Assembly with a Strong Name
To create a strong name just go to the SDK Command Prompt or Visual Studio 200X Command Prompt then type in the following
sn -k sgKey.snk
Refer this link for details
Then associate the strong name to your assembly by running the below command
al /out:MyAssembly.dll MyOldAssembly.dll /keyfile:sgKey.snk
Refer this link for details
This just worked for me after the above mentioned solutions failed:
Remove the reference to the assembly in error, then add it again.
I found my problem to be in the .csproj file
<Reference Include="OtherProjectNothingToDo">
<HintPath>..\..\..\..\Pedidos\XBAP\Pedidos\Pedidos\bin\Release\Pedidos.exe</HintPath>
</Reference>
Then I removed it using notepad and it is okay now.
Using Adam Robinson's solution allowed me to publish, but I found that users could not install the project once it was published, as the end user system would complain of an inability to install, noting hard drive space. As this seemed highly unlikely to be the root cause, I looked further into it.
Apparently the basis for my problem was that one of my references was also referencing a .dll that my project used, but a different version. ClickOnce was not having this, and refused to copy the second version of the .dll to the user's system, citing the version already present. Fixing it so the .dll and the project referenced the same version of the other .dll removed the error and corrected the install problem.
Check that the Target Framework is actually set to 3.5 or whatever framework you want to target. Sometimes it will error out when it's not set properly.
I just had this problem too. In my case the blabla.dll was referenced in my solution but blabla.dll was also used in another.dll which i had referenced in my project.
On checking the versions of both blabla.dll they were not the same. So i updated another.dll with the correct blabla.dll and then referenced the new another.dll in my solution. The error was gone.
In short: i was using 2 versions of blabla.dll
I hope this makes sense, if not let me know. :)
Check my blog for more detailed explanation:
Blog article
Regards, Jacob Iedema