TeamCity artifact includes every single file - vb.net

After using TeamCity, my build process is Visual Studio (sln) -> NuGet Pack. Everything builds fine and the artifact is created. But the artifact has every single file, include the .vbproj, .vb files, the classes folder which only holds .vb files.
Is there a way to turn a setting on to create the artifact which doesn't have all the .vb files etc due to them being compiled in the .dll?

For anyone wondering, I just excluded the .vb files in the nuspec

Have you considered using Octopack to package the nuget. It is smart enough to include all the required files into the package and will not require a custom nuspec file that you would need to source control and manage for any future changes.
IMO custom nuspec file should be used only if you have a very specific requirement such as if the target directory is different.
(mark as content and copy always for the files that you want to include)

Related

In which file do you set nuget packages for a .NET Core project?

I found something called "MyProjectName.deps.json" in the "bin" directory. But if i delete the "bin" directory and build my project again it gets created again. Where does VisualStudio pull this data from (which packages should be included in the project)?
This is based upon the obj\project.assets.json file (generated by NuGet restore) which defines inputs to the build logic that are used for the generation of the .deps.json file, along with other references from the project file.

MSBuild: Is it possible to specify projects build dependencies in actual project file?

I have a number of different MFC language resource files in an MSBuild system, and I'm trying to build different dlls from each. I have a project file for each in the same directory.
What I'd like to do is specify in the main project file the other project files of the resources to be built.
If I use the
<Import Project="lang_de-DE.xml"/>
construction, the main dll will contain the code from the imported projects (according to MSDN MSBuild documentation).
I don't want to use the
<CreateItem Include=.../>
construction either, I have them all in one directory.
I have lang_main.xml, lang_en-GB.xml, lang_fi-FI.xml, etc. in on directory, and the .rc files for these in a different directory.
What I need to do is have the lang_main.xml project file build the others first, and then build itself, and have the same number of dlls in the end.
Is it possible to solve this?
Thanks
Solved.
What I did was create directories for all languages on the same level with the main language, and put a project file for each of them into the corresponding directory.
Then, I put all the resource files into the main language directory, and in the separate project files I reference their own rc file, by relative path.
Then I used the other language "modules" as dependencies in the main language module, in its project file.

Augmenting set of project output files in MSBuild

Is it possible in MSBuild 4.0 and/or 4.5 to specify additional files to be treated as a manifest output of a project by its dependencies, and copied with the binary project output, whenever that is copied? Ideally, I want to create some files beside a .dll during build, and would like these files to stay in the same folder as the .dll whenever it is copied to a directory of a project depending on it.
If this is not clear, I am thinking of .pdb and documentation .xml files created by the C# compiler. These files treated specially: Whenever another project requests the .dll be copied locally into its binary directory, these files go with the .dll. Can I augment this set with my own special files?
This is not possible, and here is why. Actually, there is no concept of project output accessible externally between MSBuild projects. Rather, when a reference to a project is added, the SDK-provided build framework (based on MSBuild scripts) looks for a few specific files matching the name of the referenced DLL, and copies these files with the DLL itself into the current project output directory (assuming CopyLocal is set, which is probably true for a referenced project).
In framework v4.0, this is done by the task ResolveAssemblyReference which is called from an identically named target from the file %windir%\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets. The task looks for specially named files placed beside the target DLL, including its matchin PDB files and an XML documentation file. Other files are also discovered, as I infer from the decompiled source.
So nothing in a given project specifically marks these files as somehow "exported" from the project. The magic happens on the pulling side.

Visual Studios 2010 Shared Project?

I have been searching around for an answer to this question, but I cannot find the documentation on it. I found a few similar questions asked here, but none that completely cover it?
Similar Question
What do all of the different files in the project directory do? I am trying to make my project open source and I don't want to have a ton of unnecessary files in my repository. What files are vital and what files will be generated when the user initially loads the project? Its important to note that this is a VB Form Application
Base Directory:
*.vb
*.Designer.vb
*.resx
*.vbproj
*.sln
*.vbproj.user
*.config
Any of the other folders in the base directory?
*/bin
*/Collection
*/My Project
*/obj
*/Resources
*.suo and *.user files can be ignored. They store user specific settings such as window arrangements, open files etc. Those files are generated by Visual Studio whenever a solution is opened.
*.vb files are somewhat important since they contain your source code...
*.sln and *.vbproj files tell Visual Studio which projects are in a solution and which files are in a project, respectively. They also contain project specific settings such as build plattforms, custom build events, target .NET Framework etc.
*.resx and app.config can be important, depending on your project. They should not be left out when you publish your project, however since they're part of the Visual Studio project. If they're truly not needed you can remove them from the project.
Edit
Folders bin and obj are where Visual Studio generates the compiled output so you should not include those when you publish the source code of your project. Any other folders are project specific so it depends on your project if they're needed or not.
As a rule of thumb, anything that is automatically generated should be excluded when you publish your source code.
Also, if you don't already, you should use a version control system such as Subversion or GIT to manage your sources. Any essential files / folders as explained above should go in there.

How to create WiX.targets file

I'm working on an existing WiX project. The project imports a wix target file.
<Import Project="$(MSBuildExtensionsPath)\MyCompany\MyTargetFile.targets" />
Unfortunately, I cannot seem to find this file anywhere. How was it created in the first place?
As you may know, WiX project files are Visual Studio project files, are MSBuild project files. Target files are MSBuild project files but only contain MSBuild targets that might be used in building projects.
$(MSBuildExtensionsPath) is a common place to put targets files. From the name of your target file and the fact that is it is located under $(MSBuildExtensionsPath), I'd say, you are looking for one that was written by MyCompany and planned to be used by several projects. You might find it on another machine at MyCompany—perhaps on a build server.
Some useful links:
MSBuild
MSBuild Targets
How to: Use the Same Target in Multiple Project Files