I recently changed my project's dll name from ObjectCreator1.1.dll to ObjectCreator.dll. This project also creates an XML documentation (Properties->Compile->Generate XML Documentation file). Now the problem is that I have renamed my assembly name with all the proper steps, and when I compile my project I get the right .dll and .pdb files, but the file name of this XML file is always ObjectCreator1._1.Template.xml. Is there any way I can rename this file to ObjectCreator.Template.xml?
I tried compiling my project without "Generate XML Documentation file" checked, and I recompiled after that with the "Generate XML doc file" checked... but somehow it is still taking the old assembly name.
Any idea from where it is taking this old name from or how I can rename it? It is a VB.NET project.
For a WinForms project it takes the name from the Assembly Name (specified in My Project under the Application tab).
I just changed the assembly name in my current project and recompiled, and a new XML file with the new name was generated.
For library projects, the name appears to be taken from the Root Namespace field instead.
If it's not working for you, try doing a full solution clean and rebuild.
Related
I have built software that is capable of exporting DTSX package automatically. This package among other objects has also a ScriptTask (C#). All are compiled and run just fine.
Now the new requirement is to call a class in that ScriptTask, which exists inside an external DLL we have built, so other applications can consume the same code. We did our homework, and we included this DLL into the GAC successfully during the installation of the software.
The problem is that "using our library" is still not recognized in the script.
While searching a little bit, we figured out, that we need to reference this DLL also inside the References folder. This we can do it of course via DataTools / VisualStudio UI.
The issue is that we need to do that programmatically:
We have this piece of code that generates the Project
task.ScriptingEngine.VstaHelper.LoadNewProject(task.ProjectTemplatePath, null, "MyScriptProject");
And also, we have this piece of code that creates the MainScript
task.ScriptingEngine.VstaHelper.AddFileToProject(ScriptName + ".cs", MainScript.ToString());
I am unable to figure out how I can include the reference DLL programmatically.
Updated Answer
You can programmatically update the script task by replacing the appropriate XML node in the the DTSX file
The node path depends on where the script task has been created within the SSIS package, in my case the node path was
/DTS:Executable/DTS:Executables/DTS:Executable/DTS:ObjectData/pipeline/components/component[#refId="Package\Data Flow Task\Script Component"]/properties
The #refId you will be looking for will start with Package \ Dataflow name \ Component name
This node will have sub nodes which contains the C# scripts as well as the binary that was built off this script
The property name "SourceCode" contains the C# scipts in an array called arrayElements, the array will have three sub nodes for each file, these subnodes are called arrayElement, first value is the relative path and name, second is file encoding and third is the file content
The property name "BinaryCode" contains the .dll that was build from the scripts, it also contains an arrayElement array with two entries, first the dll name and the second the base64 encoded dll binary
To get the data to populate these items you will need to create a template of the C# build directory, apply your changes, build the code and take the resulting files and replace them on their appropriate nodes
To create the template open the script via SSIS task,
Click on the project in solution explorer to and go file save VstaProject.sln
Go to the saved folder, you get the folder off the solutions properties dialog
Copy this folder somewhere so that you can reuse it to build your custom stuff
Modify the .cs files in your template directory and add your custom reference dll's to your .csproj file
Call MSBUILD in the same directory as your .csproj to output the dll, its important that you use the VS MSBUILD, VS2017 you can find it in
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe
Take these files and package them into a XML node in the DTSX file
Initial Answer
Microsoft provides a workaround for loading DLL's that aren't in the GAC
Load assembly that isnt in the GAC
Please see below extract from a SSIS script, I loaded the JSON dll's from the nuget install directory. This DLL is not in the GAC
static ScriptMain()
{
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
}
static System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
if (args.Name.Contains("Newtonsoft.Json"))
{
string path = #"C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\plugins\Diagnostics\";
return System.Reflection.Assembly.LoadFile(System.IO.Path.Combine(path, "Newtonsoft.Json.dll"));
}
return null;
}
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)
I am trying to ensure that the .dll.config file generated in a reference project is pulled into the parent project's /bin directory during a build. I've read here and here about using the AllowedReferenceReleatedFileExtension setting in the parent project's .vbproj file, but I'm getting a warning:
The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'AllowedReferenceRelatedFileExtensions' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003'
the property group I added to the end of the .vbproj file looks like this:
<PropertyGroup>
<AllowedReferenceRelatedFileExtensions>
.pdb
.xml
.dll.config
</AllowedReferenceRelatedFileExtensions>
</PropertyGroup>
I'm a little out of my depth with .net builds, so I'm not sure where to start trying to resolve this warning. There are a few other similar warnings in the .vbproj file that don't seem to be causing any problems, but running the build after I added this section didn't actually copy the reference project's .dll.config file over.
Any ideas?
According to this answer (which worked for me), it seems you need to add a semi colon after each extension.
Not sure if that is mandatory
Set the build output verbosity to Detailed and see where the dependencies are being copied from. It is possible that your target dll is referenced indirectly from multiple projects and it is being copied from the project that does not have the AllowedReferenceRelatedFileExtensions set.
In the build output search for:
Dependency "your target dll"
Resolved file path is "path where the target dll is being copied from"
P.S.: "Target dll" means the dll whose .dll.config is required to be copied to the referencing project's output folder.
Did you try to use MSBuild instead of add tags manually?
MSBuild.exe MyProject.csproj /t:build "/p:AllowedReferenceRelatedFileExtensions=.pdb;.xml;.dll.config"
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.
I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!