A C++/CLI project I maintain using VS2012 mysteriously stopped creating a .metagen file for one of its dll's for one build configuration. The metagen file is still created for other build configs. We use the metagen files so I need to build them for all configs.
I've tried searching project properties for differences between the broken build config and others, but saw nothing that seemed to have anything to do with metagen files. I've also searched online and found nothing useful about creating or suppressing creation of these files.
How do I turn metagen file creation back on for this dll in this build config?
I just solved that same problem when I understood that Visual studio was actually driving me to search at the wrong place. Indeed, my release build aborted and the first error message I saw repeated (eating all the error window) was unresolved symbols followed by indications of a missing metagen file...
All this was actually a consequence of a DLL link step failure much earlier in the build, that same DLL out of which the 'metagen' is possibly (automatically) extracted. So I advise you to go through your project dependencies in your solution and perform 'project only' builds step by step until you find the first failure. And best you look at the 'build ouput' panel to see the first error that arises instead of trusting the 'error' panel to present you with the root cause at the top.
In my case it was a silly mistake in a library directory path that entailed a subsequent DLL link failure, that entailed subsequent XAML unresolved members in that DLL namespace, that entailed plenty of missing metagen file errors...
Related
I have absolutely no idea, what does it means? I only press OK in assembly information in order to specify Assembly Version.
What paths is absent? And what operation VS2022 can not finished? It looks as Visual Studio programmers what is useful error messages are.
I just ran into this problem and for me it was a VB project, and when you modify the AssemblyInfo, it tries to write the AssemblyInfo.vb file to the .\My Projects\AssemblyInfo.vb. Normally when you create a fresh project, I think this folder is created automatically so VS assumes it's there and gives you this error if the folder is missing.
In my case the folder was not checked in to git, so when I checked out the project the folder was not there. I would assume the same is true for c# projects, except the folder expected would be .\Properties\AssemblyInfo.cs.
All I had to do was create the "My Projects" folder at the root of my project and the error went away. It appears you are using c#, so try creating a "Properties" folder at the root of your project and see if the error goes away.
I still don't understand what path Vs2022 can not found and what operation VS2022 can not complete, but manually add CS-file with needed attributes solve this issue.
We are using TFS 2012 to build our solution. Once this is done I use the build output to create some NuGet packages which I publish internally. I have just started building these packages with symbols as well so that I can publish these NuGet symbols packages to our internal Symbols Server.
However I am having trouble publishing the symbols packages to the Symbols Server. The reason is that the DLLs and PDBs don't match. I used ChkMatch and indeed the age property is different on the DLLs and PDBs that sit in the TFS Dropfolder Release directory. If I grab the PDB files instead from the obj folder in the actual build directories then they match.
Now I believe that the age property is getting incremented because my Build Process Template has the property "Source and Symbol Server Settings > Index Sources" set to True.
Is it correct to just set this property for false?
Will there be any unforeseen consequences?
If I am using NuGet to publish my symbols can I just ignore an Source and Symbol Server Settings in the build process template?
The age discrepancy raised by chkmatch is misleading. As discussed here (bottom comments section) , it should not prevent Visual Studio from finding the matching Program Database file (PDB) and loading the Symbols.
I have been struggling with this and thought that the age difference was preventing me from stepping through the source code being indexed. There was another issue at hand and it got me on the wrong track. So, a word of caution regarding the age property difference when using chkmatch to debug such issues.
I am making changes to a web forms application in visual studio 2012 and part of that change is to remove reference to an old dll. The dll is responsible for handling authentication and I have written a new class library to handle this.
My problem is everytime I build my website in the solution, it always generates this old dll. I've annotated out all references to it in the entire application and it's not in the project dependencies of the solution.
If I exclude the unwanted dll, it just generates a new one. I am completely baffled by this. It's something I've not encountered before so I am not sure what else I can do.
I'm not sure what to post so if anyone can help then that would be great.
I had a similar problem (but it was with a persistent DB file being generated). I ended up having to go through the bin from the project file and editing it from there. Some files are 'hidden' from the project, and are either visible by
Make sure you are showing all files. There is a button at the top of
the Solution Explorer called "Show All Files". To see this button,
make sure that your project is selected in the solution explorer.
or by manually going through your project files.
EDIT
It can sometimes be hidden in the Global Assembly Cache (GAC) where it can reside indefinitely. http://msdn.microsoft.com/en-us/library/zykhfde0.aspx explains how to remove it (if it is indeed hiding there).
try this, remove the old project from your Solution.
When I publish a ClickOnce application, one of the references that is included in one of my projects is missing.
If I go to my project's Properties -> Application Files, this missing reference is not even listed here.
My bin/Release folder has an .exe.manifest file, and I noticed it that it is also missing from here.
However, when I build the project, the DLL is in fact copied to my bin/Release folder.
How can I ensure it also deploys this required dependency?
I finally found a solution for this problem and I hope it will solve your problem to.
In my case, I'm editing an old application at work which have multiple projects, but the main project and it's back end project are the most important here.
The back end is added in the References section of the main project.
In the back end, a third party dll was imported, but this dll requires 2 other dlls.
So those 3 dlls were added in the References section of the back end project.
At that point, one of the 2 other dlls was not showing in the Application Files section for ClickOnce.
I've come up with a couple of ways of fixing it, but the most elegant one was to add this dll in the Reference section of the main project.
As stated in How to: Specify Which Files Are Published by ClickOnce, change the Copy Local property value on the reference to True.
References to assemblies (.dll files) are designated as follows when you add the reference: If Copy Local is False, it is marked by default as a prerequisite assembly (Prerequisite (Auto)) that must be present in the GAC before the application is installed. If Copy Local is True, the assembly is marked by default as an application assembly (Include (Auto)) and will be copied into the application folder at installation. A COM reference will appear in the Application Files dialog box (as an .ocx file) only if its Isolated property is set to True. By default, it will be included.
I know is this an old question, but for anybody having similar issues. I think this is a cleaner way around the problem.
I had a similar issue and everything I did to get ClickOnce to deploy with the offending .dll failed.
Eventually, I had to deploy manually.
See walk-through here.
That worked for perfectly for me. But, for the life of me, I still wonder why that process can't be added to VS (I'm using 2017 community).
I have been working with setting up TeamCity, and I have almost everything working with the exception of being able to compile VS2005 solutions that have referenced assemblies that are outside of the solution path. I have our SVN repository structured as follows
Root
Libraries
Project 1
Trunk
Project 2
Trunk
Project 1 and Project 2 reference third party assemblies located in the Libraries. This works just fine from within the VS2005 IDE and when calling MSBuild on the solution files since the HintPath for all of the references look like this:
..\..\..\Libraries\ThirdParty.dll
The problem I have encountered is that when TeamCity dies the checkout from SVN for Project 1 or Project 2, it places everything into internal directories that don't match the structure of the relative path given by the HintPath.
How do I go about clearing this up, either through a TeamCity configuration or configuring my solutions/directory structure differently? Either one will work for my needs.
Thanks!
If you create a separate VCS root for Libraries, you can use checkout rules to control where the files are placed in the directory structure so that it matches the structure on your local machine.
We set up a network directory with all our third party dlls. Then we mapped the directory to a drive.
That way the dlls weren't a part of our solutions and all projects just call z:\3rdParty\example.dll to get the assemblies.
Someone else on my team actually set up our teamcity, so I could be completely mistaken about how the problem was actually fixed or if we even had that problem initially :)
What i have done is to set the VCS ROOT of the project to the top level directory ("Root" as per your project structure). And detached the default project vcs root created by teamcity. After this you can create a custom build step by specifying your solution here "Solution file path: *" in build type "Visual Studio (sln)". Now it properly handles library references.
There is a drawback here in that, since the vcs root is at the top level, even unrelated check ins could cause your project to build and that may not be suitable for time consuming builds. Don't have a workaround for that yet.