I have strange issue regarding visual studio 2013 after migrate from visual studio 2010 envinorment. It's about when i do some changes to any of my projects and then rebuilt it, my other's projects which have reference to those dlls are not updating. Do you know how to force visual studio 2013 to update all my projects when some of them change its dlls? Somehow vs 2010 did that.
What i did as additional so far:
- was tried to make project order built and dependency (not working)
The only way it can work for me is to delete dll from certain project and make reference once again.. ;/
think i found out the solution - just for those projects which are referencing to libraries projects, after libraries project/s are changed and built it seems if i do Unload on the project/s which are consuming those changed libraries project/s and then reload + rebuild dll's will be updated.
P.S Still looking for more convinient solution
Related
We have a developer team and there are many projects/solutions. So there are some projects which are used in some solutions.
For example project X is used in Solution A, Solution B and Solution C..
Our team have added the project as a reference instead of dll. So if somebody has change the code and commit to TFS and another developer pull the repository, so project X has been changed and the developer has to make combile the new project X for his solution because the project X was added as a reference.
So, i know that its better to add the dll file of project X and other solutions will not be effected by project X changes.
However, we have just started to use TFS build and i think that something going wrong. We have a Relase folder that contains only buildt DLLS in TFS server and the project has reference from these DLL. But in local machine, our team uses dlls which are build of project X instead of adding directly Project X as reference. But still if project X has been changed and compiled then the build DLL will be changed and the solution has to be reviewed again.
I know its a bit complicated but my question is that How we can add reference as DLL for all team (with versioning). For example all developer's computer has C:\Development\Relases folder and we can add Folders like
Project X 1.1
Project X 1.2
and the developers directly reference dll from this folder considering versions. But for example if another developer made a new version of Project X 1.3, i want to see also new dll on C:\Development\Relases folder.
How it can be possible and is it a good solution? If not what is your advice?
PS: We have VS Ent. 20015 and Microsoft Visual Studio TFS 14.102.25423.0
Usually the solution will using the latest dll buildt by project X. You may could check in the dll in TFS as source control. Even though source control dll is not a recommend way, but this maybe the best practices to meet your situation.
Then you just need to manage the dll the same as other external dll. Detail ways you can refer the answer from Will in this question: TFS dll and references issues
Using Visual Studio 2015 Enterprise on Windows 10 64-bit. Working with a solution which contains a bunch of C# library projects.
When building the solution, then building it again, then repeating this, each time there are a handful of projects which build every time. There have been no changes to any of the source files, yet VS still wants to build these projects.
Anyone have any tips on debugging the build dependencies to figure out WHY it wants to build these projects each time?
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
I'm looking to upgrade a VS2008 project that's currently on TFS2008 version control, with the eventual destination of VS2012.
One thing I'm wondering is whether it would be better to upgrade the project incrementally, to VS2010 then VS2012, or just go straight from VS2008 to VS2012?
The second question relates to versioning--I would like ideally to keep continuity in the versioning, mainly to make it easier to do a diff and see what's changed in the project files etc. So should I keep the project linked while I upgrade the project? Or should I unlink, upgrade, and then relink to the main trunk?
Would it be a bad idea to branch, upgrade the project on the branch, then merge back to the trunk?
My overall plan is to make a copy of the 2008 project, compile the project, run ILDASM on it, upgrade the project, resolve all compiler errors, then go through the list of breaking changes for VB and try to track down and fix any "silent" changes, compile, run ILDASM on that, and do a diff to see what's actually changed in the CIL.
VS2012 will connect properly to TFS 2008. Just check out the files and open with VS2012. You can then do a file compare to see what has changed and check in if everything is ok. No need to go through VS2010. VS2012 files are VS2010 compatible.
It seems like it's still not possible to build .vdproj on a build-server without having Visual Studio installed. However, using Wix seems to be a lot more complicated.
Are there any other options to do the following task:
Visual Studio 2010 Solution with multiple projects (.csproj)
Many loose content files (not inside assemblies)
Installer must be built on Build-server without Visual Studio on it (devenv.exe / devenv.com)
Installer must create Registry keys
Installer must associate file extensions with installed product
Installer must support upgrades (version upgrades)
Installer should be able to register COM components
Installer should be able to pre-JIT assemblies
My goal is:
Effort to maintain installer is low
Minimal changes if new project (assembly) is added to solution
Ideal: no changes if new content files are added to any of the projects
Maybe I just did not get the point with Wix, but including project output (like in .vdproj) seems very complicated.
Any suggestions very much appreciated!
OK I decided to go with Wix. Found out that using Votive it's possible to include project output like in .vdproj (Binaries, Content, Symbols and even Source Code).
If I run into more complicated situations where this isn't sufficient, I could fall back to some kind of harvester (Heat, Paraffin).
See some more Links in comments below (too little reputation to post more than 1 link in this post).
Check out InstallShield 2010 Limited Edition ( Free for Visual Studio 2010 users ). It has pretty much all the functionality that VDPROJ ( being retired btw ) has and supports silent builds. You can get one license for your dev box and one license for your build machine pretty easily.