For some reason in VS2010 I can't embed any file into an assembly. These files have their Build Action property set to Embedded Resource as they should, but when the assembly is executed it founds no resources. For example, the following test code:
string[] list = System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceNames();
string msg = (list.Length > 0) ? "Full" : "Empty";
MessageBox.Show(msg);
always shows "Empty" because GetManifestResourceNames() always returns an empty list.
This issue affects a project using nettiers in which is not convenient for that particular case to include the stored procedures into the DB, so they must be taken from the Procedures.xml file, which BTW is automatically set with Build Action= Embedded Resource after the classes generation, and then of course when a function tries to get any SQL script from it, the program fails.
I also created a couple of test projects where I tried to embed an xml and a gif, always with no success.
Update: The problem seems to be only for C#. I reproduced the test project in VB.Net and there the file does get embedded. I've noticed that in the output window, in the C# case, the compiler command line doesn't include the /resource option (which should be there followed with the name of the file to embed) whereas for the VB case it does appear.
Are there any global settings or configuration files anywhere for C# I should check? (The build options for the project have nothing strange there)
Does anyone have an idea of what may be happening and how to fix this?
Finally, I found the cause:
There was a wrong line inside the Microsoft.CSharp.targets file (located inside c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319). There was a tag written as:
<EmbeddedResourceF Include="#(_Temporary)" />
instead of
<EmbeddedResource Include="#(_Temporary)" />
Writing it right restored the ability to embed files
How that F appeared and why that file got altered in first place, I dont know... Despite being a .NET programmer for several years I just became aware today of the ".targets" files after searching the web about this issue, as never have had the need to look about the MSBuild stuff.
Related
I wish I could provide a better description, but this is hard to describe succinctly.
Let me start with some background. This is a C++ solution using Visual Studio 2019 Community Edition. It has 12 projects of different types (DLLs, static libraries, and executable tests) and 4 build configurations ((Release, Debug)x(Win32, x64)). Keeping all the properties the same across projects and configurations has been a massive pain, so I decided to try using property sheets so that I could have the properties shared across projects. Given the structure of my solution, the property sheets are themselves somewhat complicated, but it's an improvement over what I had.
However about halfway through this migration I noticed some odd behavior. When I inspect the properties for one of my projects (a static library), the properties page is almost totally empty. Not only the properties I have changed with my sheets are missing, but even the default properties that you would expect.
However when I build this project, I can tell that most of the custom properties are in fact set correctly despite being missing, so it would seem like a UI bug, except some properties are not set correctly, for example the build log is not written to the correct location despite being set in the property sheet. This makes me worried that other more important properties may not be set correctly as well, but it's hard to know which properties are getting set and which are not.
I have another static library project that is set up in the same way with the same property sheets, and it behaves normally. It shows the expected properties in the project properties, and the build log is even in the correct location.
It gets even stranger. When I run the build from the command line using msbuild or devenv, the build log is written to the correct location. This suggests that building from the command line is working correctly, and that building from Visual Studio is not the same as building from the command line.
I ran msbuild -pp to see the expanded project file, and it looks correct. I diffed this project file with another static library from my solution that is working normally, and the diff is as expected, only the project names, paths, and source files are different. I did this diff on the expanded projects files too and they were the same except the expected differences.
I have closed and reopened Visual Studio countless times. I have also unloaded and reloaded the project. I have even tried deleting the .vs folder. None of these had any affect.
Here is a link to my code.
Screenshots demonstrating what I mean.
Is there any way to fix this? Have I done something wrong? I would like all of the properties from my property sheets to show up in the project properties, and I especially need all of them to apply when building the project.
Moving the <ItemGroup>s containing the source files below the <ImportGroup>s in my project file (.vcxproj) fixed the problem. I cannot explain why this works, or why this was ever a problem in the first place, but it fixed it.
I have a wix booststrapper project, which cannot be localized like the normal WiX project.
If I extract the hard code string from the booststrapper.wxs file, then the compiler output errors:
Light.exe : error LGHT0100: The localization identifier xxx has been duplicated in multiple locations. Please resolve the conflict
Has anyone some experience in boostrapper internationalization?
Would you give some suggestions?
This issue is discussed here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Votive-Light-LGHT100-error-when-more-than-one-localized-wxl-td7587802.html
In short, if you include two or more .wxl files you will see this error. The trick is to mark the extra localized wxl files as Build Action = None in the Properties window for the actual wxl files in the solution project tree.
If you are using a main one (or a copy) like RtfTheme.wxl, that one can remain as type Embedded Resource. This is the default type Visual Studio seems to assign wxl files added to the project but only one can ever be marked as such. So long as you have Payload elements that bring in the rest they do not need to be marked as Embedded Resource and, as experienced, it will fail the build if they are.
Additionally, the following post describes a very nice way to organize all these localization files: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-td7208949.html
I am new to ANTLR. I wanted to learning start by setting up a project so that lexers\parsers would be automatically generated by the build. So I downloaded antlr-dotnet-tool package, modified a project file to include antlr targets. I also installed some VS extension that add syntax highlighting and new item types for grammar files.
Now, generation seems to works, but it puts output files into obj/${Configuration} folder. And I don't really know what I am supposed to do with them there. Surely, you don't want me to manually copy them to proper locations (supposedly next to grammar files), do you?
It would be great if you could shed some light on it.
If you followed my blog post, you will see that you need to do nothing else,
http://www.lextm.com/2012/07/how-to-use-antlr-on-net-part-v/ (note that at the beginning you will see links to the previous 4 parts)
At compile time the generated files are automatically linked to the output assembly, and the debugger is capable of loading them when you debug the program.
I opened up VS today to find this error waiting for me when I built my project. I hadn't changed anything since yesterday, when it was working just fine.
Unable to load arguments for the XmlPeek task. One of XmlContent or XmlInputPath arguments must be set.
Of course this error has no line associated with it or anything else that may be helpful...
The project is in the .NET 4 Framework with Console Output.
Any ideas as to what is going on? I tried googling this of course but the few answered I found had to do with a content pipeline (which this project does not use).
Thanks!
I received this error in case, when I have deleted Content Project of my game. It has been solved by adding correct content reference into the Content References directory.
I had two projects (proj1 and proj2) and each of them had their own content projects (proj1_content and proj2_content). I wanted to have one common content project for both projects, so I had deleted both proj1_content and proj2_content and created new content project called common_content. After that, mentioned error appeared. Solution was to go to Content References directory at each project and Add Content Reference pointing to common_content.
Due to a hardware problem I had to put in a new SSD and re-installed VS. All my projects worked except my XNA in Winforms project. Being rather large (12,000 hand-written lines of code) really didn't want to try the "copy it all in to a new project" solution above. Thought I'd try to see what versions worked. All versions prior to me adding an installer project worked. In fact, the version where I had added, then deleted the installer was broken. So I'm not sure how (or if) the installer broke it but I found one section of the main project file that had a missing entry and it did reference XNA also (all my non-XNA projects build just fine). Note that I have substituted my project's name with a reference to YOUR projects name by using <YourMainProjectName>. If your project is joesgreatproject then use that text in place of <YourMainProjectName> (don't include the <> symbols). I think this was only because the XNA didn't have a content directory and needed a reference to one.
File: <YourMainProjectName>.csproj
<ItemGroup>
<ProjectReference Include="..\< YourMainProjectName>Content\<YourMainProjectName>Content.contentproj">
<Name><YourMainProjectName>Content</Name>
<XnaReferenceType>Content</XnaReferenceType>
</ProjectReference>
</ItemGroup>
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.