Is it possible to compile Excel-VSTO workbook into the Excel-File itself?
This is my Project
But I want all the files compiled into the Excel file.
Is this possible?
No, that's not possible because in order to enable a document-level VSTO customization the workbook needs to have an entry _AssemblyLocation in the Workbook.CustomDocumentProperties.
This entry has to contain the path to the .vsto file.
If you use ClickOnce it will look something like this:
file:///DeploymentServer/MaterialTable.vsto|74744e4b-e4d6-41eb-84f7-ad20346fe2d9
If you use your own Setup.exe to deploy all files locally instead, you can specify this local path as well by appending vstolocal to the end:
file:///C:/Program Files/MaterialTable/MaterialTable.vsto|74744e4b-e4d6-41eb-84f7-ad20346fe2d9|vstolocal
This .vsto file contains the related names of the .manifest and .dll files that Excel also needs to load.
So unfortunately you just can't compile a document-level VSTO customization into a workbook because Excel needs to have physical access to the .vsto/.manifest/.dll files.
But if you're using the vstolocal deployment, you can at least specify an absolute file path so that your .xlsx file doesn't need to be in the same directory as your .vsto/.manifest/.dll files. So maybe this could be (at least kind of) an alternative solution for your problem.
Related
I have created a custom xml file which I use as a config for my application. I'm reading it by my own (I have some reasons not to use app.config or any other standart file)
I'm using it for my framework, so user who will change this config file, will use Visual Studio for editing. I want to add Intellisense, to support this config file.
I have found many solutions, but all of them are designed so my .xsd for this config file should be copied to Schema folder in VS. But I need to store it in the same folder as my .xml file. Actually I can't copy or change anything in VS folder - it should be standalone.
How can I do that?
I found an answer to my question by myself.
I need to set targetNamespace to the root of my xml, and place xsd beside with the same targetNamespace.
Don't know why it was so hard to find this information, the answer is very simple
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.
I have a Visual Studio 2010 project which references some third-party components. Their assemblies are accompanied by XML documentation files, which are useful for us (and only us) developers. And whenever the project is built (either in Debug or Release modes) these XML files are copied to the build directory.
I can't seem to find a setting or switch to disable the copy of those XML files to the build directory, either within Visual Studio or though MSBuild. A post-build script may be an option, but a smelly one. Any ideas? Thank you.
When you build a project the .xml/.pdb files are gathered through the ResolveAssemblyReference task. When ResolveAssemblyReference is called it is passed a list of file extensions for related files. That list of file extensions is captured in the MSBuild property AllowedReferenceRelatedFileExtensions. By default that list will contain ".pdb;.xml".
If you want to exclude all related reference files from being picked up then just override the value of the property to something which related files won't have extensions of. For example you can set AllowedReferenceRelatedFileExtensions to "-".
You can also customize the list of file which are returned by that. If you only want to find only .pdb files then you will need to pass in AllowedReferenceRelatedFileExtensions=".pdb". In that case any references which have .pdb file next to the .dll/.exe they will be copied as well. You can also use this to copy other related files which may not end in .pdb/.xml. For example if you have a referenced assembly named, MyAssembly.dll and in that same folder there exists MyAssembly.pdb and MyAssembly.foo If you set AllowedReferenceRelatedFileExtensions=".pdb;.foo" then both the .pdb and .foo file will be copied to the output directory.
Visual studio project file has the same format as any msbuild file. So you can manually add the condition into corresponding section to not copy your xml files if configuration name is 'Release'.
It should be changing
<ItemGroup>
to
<ItemGroup Condition="'$(CONFIG)'=='RELEASE'">
or something like this.
If the .xml/.pdb are marked as build-action "Content" (etc), you can change them to "None". You should also ensure they copy-to-build-output is false.
Are both of those set?
What is the problem with having the XML files get copied into the folder on release builds? It seems to me that this is fine and that the real problem is with the code that picks up files to place them in the installer. Picking up third party dlls from your own bin\release folder is not a good practice in my opinion. I'd have my installer pick up third party dlls from their own folder in my source tree.
The setting is in the Properties of the project in question, under the "Build" tab, uncheck "XML documentation file". It's also an MSBuild property called <DocumentationFile> under the applicable <PropertyGroup> for your build configuration in the .*proj file.
I use ILMerge to merge several of my C# project DLLs into a single DLL for the whole solution. I have each project produce a .XML file of its documentation for Intellisense, and I'm having trouble getting those comments to show up when I try to use my merged DLL as a reference in another solution. I have these files all in the same directory:
MergedProjectDlls.dll
Project1.XML
Project2.XML
Project3.XML
Project4.XML
I tried renaming a single project XML file to be MergedProjectDlls.XML then removing and re-adding the reference in Visual Studio, but Intellisense still wasn't picking up on the comments that I know are there in the project XML file I renamed.
I was hoping to somehow merge all these project XML files into one titled MergedProjectDlls.XML anyway. Is that possible? Would Intellisense then pick up on it automatically when it's in the same directory as MergedProjectDlls.dll?
Edit: just found this on MSDN:
To use the generated .xml file for use with the IntelliSense feature, let the file name of the .xml file be the same as the assembly you want to support and then make sure the .xml file is in the same directory as the assembly. Thus, when the assembly is referenced in the Visual Studio project, the .xml file is found as well.
And also:
Unless you compile with /target:module, file will contain tags specifying the name of the file containing the assembly manifest for the output file of the compilation."
Der, it turns out that's just a command-line option to ILMerge:
ILMerge.exe /out:MergedProjectDlls.dll
Project1.dll Project2.dll Project3.dll
Project4.dll /ndebug /xmldocs
If I use the publish feature in VS2008 (I think it's called ClickOnce install), and then install the published application in another computer, where are the files copied?
In other words: If I need an auxiliary file (a .txt file) in the same path of the assembly, where do I have to create it?
Thank you.
You should have specified the location when you published the application. Just note down that folder.
If you run the wizard again for the same project it should have remembered the location and the folder will be pre-filled on the form.
I've used this and I specified a location on my hard drive for the Publishing Folder Location. This folder contains the following files:
publish.htm
setup.exe
[application].application
It also contains a folder called Application Files which contains the files needed to build the installation - the exe, the manifest, other dlls and external resources.
I then copy the three files and the folder to the web location specified by the Installation Folder URL.
If you're talking about where the files get installed to then they're in:
C:\Documents and Settings\[user]\Local Settings\Apps\2.0\H165QZM1.QBE\0OAEZTRX.Y3N\[some truncated version of the exe name followed by a GUID]
Which isn't the most obvious place. I should also point out that the folders H165QZM1.QBE and 0OAEZTRX.Y3N will probably be different on different machines, but the only other folder under C:\Documents and Settings\[user]\Local Settings\Apps\2.0 is called Data so they should be easy to spot.
Is the application available offline or online only? My experience is online only and in that case I believe it installs into a temp directory. Can you include your auxiliary file as part of the application files? This may help as well it talks about including data files which can be of any type.
http://msdn.microsoft.com/en-us/library/d8saf4wy.aspx
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx