I just opened a solution from TFS using Visual Studio 2010. The solution contains more than 100 projects (if up to me, it would probably be less than 5) and many of them happen to miss a reference (to Unity dll's).
Is there any way to simplify the fixing of these references? Now I have to delete and re-add all of them manually. Hassle.
Any suggestions would be appreciated.
To fix the problem you need to find out from where it tries to load the files. You can do so looking in the project csproj file. You either have newer (or different) versions of the assemblys installed or you have a different file and folder structure. You need to recreate the file and folder structure that has been used in that project or rewrite the csproj file to the new location.
For the future you might want to change how 3rd party references are handled. I have good experiences using this approach: Define a ThirdPartyLibraries Folder where all those libraries go and check it in. It should be in the solution folder. Everybody has to put 3rd party libs in there from now on and use them instead.
Might want to check out resharper, it might do what you need for references. I know it helps optimize and identify references in classes, not sure at the project level. Resharper has a 30 day trial
You can add all those binaries in to Binaries folder and add in to your TFS.
Now add the binaries as existing item in your solution items, so that when you open the solution it fetches all the solution items as well.
Make sure the references are added from the binaries folder.
If the location of the referenced assembly has changed, then it is relative simple to do a Find and Replace in files on the .csproj files to replace the broken reference with the correct one.
Related
Ever since I've been using the (relatively) new .NET Standard Library project type in Visual Studio, I've been having some problems getting a complete set of DLL files that are required by my project.
The problem is usually limited to 3rd-party libraries which I reference as NuGet packages. I've noticed that these don't get copied to the output folder of my project when I build it. This didn't use to be the case in classic project types.
While I can appreciate the de-cluttering effect that this change has brought for .NET Standard projects, I'm now faced with a problem. I sometimes absolutely need to be able to get the entire list of all files that my project depends on!
I have several different cases, where I might require this list for one reason or another, but the one I believe is most crucial for me, is when I want to gather these files from the csproj itself, right after it's built. In there, I have a custom MSBuild <Target> which should take all the files from the output dir and zip them together for distribution. The problem is, I'm missing all the files that come from NuGet dependencies, because they're not there!
How can I solve this in a general (i.e. not project-specific) way?
UPDATE
There's this deps.json file that contains basically all I'm after and then some. It's just a matter of extracting the relevant information and find the files in the local NuGet cache. But that would involve writing a specialized app and calling it from my target. Before I start writing one myself... Is there something like this already out there somewhere?
I followed this answer and it sort of works.
The suggested thing was to include the following into my csproj:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
My main concern is that it also outputs some other DLLs from the framework (such as System.Memory.dll and System.Buffers.dll, among others), which I didn't expect. But maybe that's a good thing. They do seem to be dependencies, just not direct ones. I'll see how it plays out.
If it turns out ok, my only wish would be that this directive was more prominently displayed in project settings (as a simple checkbox, maybe?) so I wouldn't have to hunt the web to find it.
My question is pretty basic, I understand what AssemblyInfo.cs is, but why is there a Temp version generates in the same Properties folder? What is it used for? Do people usually add it to their .gitignore?
I believe it's what is generated from the MSBuild/csproj build. I'm not sure what process would be generating that otherwise - check for nuget packages and other things in your csproj that might be generating it.
Generally should should add bin/ and obj/ (where this file is placed) to your .gitignore.
We have a Project with a number of different solutions files and each solution then has many projects. The problem is that there are projects that need to be built for certain solutions. Each developer has to go through the pain of opening a large solution (a solution that contains many projects). The problem is that these solutions don't always build because a certain build order has to be followed.
My question is, is there a way to identify dependencies for each project in a given directory and then build these projects. Something like find all the project files that don't have any dependencies on our other projects that we own. So build such projects first then build the ones whose dependencies are already built.
I was thinking of using F# or Fake to do this but I am not sure where to start or if it is even possible.
I would really appreciate an answer with an example or links to where I can get help.
Regards,
Nasir
If you want to go with something off the shelf. Resharper from JetBrains has a very nice tool for viewing project build dependencies. This will help you create a build script with the correct build order.
http://www.jetbrains.com/resharper/webhelp/Architecture__Project_Dependencies_Exploration.html
Implementing the analysis in F# yourself wouldn't be too complicated.
For example, you can do it in 2 phases:
1. Go through your solution folder structure and build a map of (project file name -> full path of file).
2. Go through all the files you found, and for each file add references to other solutions projects to a graph structure.
Then you build progressively projects that don't have any (yet unbuilt) references.
Project files are easy to parse, being XML. Solution projects can be recognised by the relative path reference:
<ProjectReference Include="..\MyProjFolder\MyProjFile.csproj">
<!-- --^ -->
I am dealing with a really huge work such that we have a solution and there are about 100-120 projects under it. Once I was trying to launch it but it took extra long I had to cancel it. Now a number of dll files under bin folder are lost, and most of those files were created by fellow projects under the solution.
Now I cannot rebuild/build.
Till now:
-have cleaned and tried to rebuild the solutions and project folders(each folder, is directly under solution contains like 5-6 projects) one by one. I also tried rebuilding projects one by one but it took too long and was useless.
-cleaned the solution, restarted visual studio(even the computer itself), but did not worked.
-cleared the Temporary ASP.NET Files under C:\Windows\microsoft\\ TEmp... and failed to relaunch again.
-Also tried to manually add missing references to projects but since there are over 100 projects it is not useful and will not work.
Any help will be appreciated greatly.
Thank you for your time.
try everything...(in order of a little to a lot of time wasted)
Do you have bad code? Fix that first.
Clean Solution & Restart Visual Studio
Remove / Add References
Check your build order w/ larger projects and verify
Manually rebuild sub-projects
Manually copy dlls between projects into associated bin folders
Go get some coffee, play some pinball and come back tomorrow...you may think of something else in the meanwhile.
I've been there before, it is a painful process. After you do what Vignesh told you, or while you do that, you can also use Dependency Walker to help figure out which dependencies are missing. This tool from the old days is still available for free and has helped a poor soul many times over. The main download page is dependencywalker dot com.
An additional tool to use is CheckAsm. Simplified, CheckAsm is a dependency walker for .NET.
It shows all .NET assembly references for any of your .NET assemblies. This tool is located at amberfish dot net. (They have an evaluation version which is free.)
I wish you well.
We decided to delete the current solution and get it back from TFS and it resolved our problem.
I have a c# ClickOnce application that I need to be able to publish multiple times for OEM purposes.
The way I understand it now is that publish settings are located in the .csproj file.
However, this is inconvenient in the case where I want to publish multiple versions.
for example, Company A needs totally different icons, start menu location, product name etc. from Company B, but the assemblies need not be renamed.
Here are a couple approaches/questions that I can think of to solve this issue...
1.Is there a way to create a separate publish settings file to use during build time?
2.Can I edit specific publish settings (like Start Menu location, etc) at build time with MSBuild.exe? I think this would be ideal...
e.g.
MSBuild.exe project.sln /target:Publish /property:edit-project-publish-settings-here
3.Maybe create a 2nd .csproj file? (Would prefer not to do this...)
Please share your thoughts as to the best approach, or any other clever ways to make this happen. Thanks!
I wish I could give you some brilliant solution, but personally I would probably go with option 3.
I mean, its pretty simple, the changes should be pretty static and it will be difficult(ish) to totally screw it up and deploy the wrong changes to the wrong company.
If you copy the .csproj in your project folder, it will reference all of the same source files and you can just change the executable name. Create another VS solution and you can reference the copied .csproj and get rid of your first one so that you can publish two separate versions.
This isn't ideal for ClickOnce however.
If you use a Singleton object that specifies the "mode" (Company A, B, C, etc.) you can easily store that in the app.config (or another xml file). Then just re-publish your ClickOnce Application but copy the correct version of your configuration file in so it gets shipped with the build. This way, you don't need any additional csprojects Just include all of your icons and set them at run-time on App Start based on your Singleton object.
I found that you are able to edit certain properties using MSBuild.exe like this
MSBuild Solution.sln /target:publish /property:ProductName=ProductA\;Publisher=CompanyA\;ApplicationIcon=companyA.ico
I found another useful post on modifying.csproj files programatically with .NET code. (This would only be needed if you're modifying things that are deeper than just the project properties specified in the ClickOnce documentation below)
The MSBuild documentation here was also useful -- especially under Publishing Properties