Previously I have been using this method to build msi's on our tfs-server. Now I have upgraded to wix 3.10 and I can no longer find a wix.targets file. I also cannot find any information pointing out why it has been removed.
Does anyone know if this approach has been deprecated, and if so, what is the preferred method to build on TFS?
Do I just need to change the wix 3.8 targets file?
edit:
I found a wix.ca.targets file in the SDK folder, but it does not seem to be quite the same. At least it does not work out of the box for me.
The current documentation is here: http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html.
Wix.targets ships with WiX v3.10. It's installed to C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x (on a 64-bit system) and available in wix310-binaries.zip in the bin subdirectory.
Related
I had successfully built the CEF with proprietary_codecs enabled, but not getting any way to use that inside my Visual Studio project.
Below is my binary_distrib structure. I just made x86 Debug-build
Currently in my Visual Studio (WPF C# Project) I'm using NuGet for CEFSharp, how I can replace the cef binary of nuget with my own built?
I need it cause by default CEFSharp not support any video codec so I needa use my custom built
I am more familiar with nuget. Not sure your issue is related to nuget. As a suggestion, you should use some scripts,especially, automate-git.py command-line arguments
And also do not forget to use the system environments to include them.
You can check this similar issue and this document.
Besides, if this do not help, please contact with CEF Forum.
Well we are using the CefSharp windows forms. We also replace CEF build to enable proprietary_codecs.
After you build your CEF and you must make sure you are building a matching version for the nuget, you should get the following files (some are optional) from the folder (\chromium_git\chromium\src\out\Debug_GN_x86) ..
locales folder
swiftshader folder
cef.pak
cef_100_percent.pak
cef_200_percent.pak
cef_extensions.pak
chrome_elf.dll
d3dcompiler_47.dll
devtools_resources.pak
icudtl.dat
libcef.dll
libEGL.dll
libGLESv2.dll
snapshot_blob.bin
v8_context_snapshot.bin
Copy these files to your application output folder which will replace the files from the nuget.
For our case, we have copied these files to a folder next to our project and it is included in our git repository, and in visual studio we use after build events to copy the files after each build.
I am wondering if anyone can help me, I did a fresh install of MonoDevelop on a fresh install of Ubuntu 18.04.2 LTS with .NET Core 2.2 installed (everything updated), then followed the instructions layed out at Mono Download Offical. I have no errors or warnings during installation.
When I create any type of project or open one, all the system namespaces are missing?
I have checked here:
And
When I build / Clean any project I get:
/home/ant/.cache/MonoDevelop/7.0/MSBuild/27259_1/Microsoft.CSharp.CurrentVersion.targets(5,5):
Error MSB4019: The imported project
"/home/ant/.cache/MonoDevelop/7.0/MSBuild/27259_1//Microsoft.CSharp.Core.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk. (MSB4019) (sadsad)
Error
I solved it temporarily:
I went to the Namespace/Class options and under Run - Default - Advanced I selected Execute in .NET runtime -> Mono 5.20.1.34
It fixes the problem until i restart Monodevelop.
I'm having this problem since this morning, even after a fresh reinstall.
I am using Ubuntu MATE 18.04
This was a problem with mono its self, mono updated and was using a different version of MsBuild which the IDE could not use/understand. So I pulled the preview repository, as they added a fix there.
To fix:
purge monodevelop and mono-devel (with others) and install from here Preview - Stable until they patch the normal repository
I had the same problem with Monodevelop under Raspian (Rasberry3)
I believe I can now offer a viable solution:
It's just a setting that has to be done in Monodevelop before you start a new project:
Search under the settings, create and disable the line "create with MSBuild instead of xbuild".
After that all new projects will be recognized without errors.
For old projects the procedure is similar:
but there you should delete the folder ".vs" in the project folder first (better make a backup copy first! ;) ).
Start Monodevelop. Check that the settings are as described above.
Then open the project in Monodelop.
When you open the project, it will be reinitialized and can then be edited and compiled without any problems.
I am building an app in Visual Studio 2015 to allow people to see the changesets of a TFS server.
I found some an example code, however it requires a reference to Microsoft.TeamFoundation.Framework.Common.dll, but I couldn't find the DLL in the Reference Manager.
I have also searched the server which has TFS2015 installed, and I couldn't find there either.
Does anybody know where to find the dll?
This might be installed in your local development machine. If so then the dll (Microsoft.TeamFoundation.Common.dll) can be referenced by browsing for it.
Another solution is to install the Nuget package Microsoft.TeamFoundation.Client. Once installed, it will be ready to use for every project this package has been installed for.
Note: Be sure to check-in your packages folder if using version control.
Namespace: Microsoft.TeamFoundation.Framework.Common
Assembly:
Microsoft.TeamFoundation.Common (in
Microsoft.TeamFoundation.Common.dll)
Source : https://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.framework.common.configfileexception(v=vs.120).aspx
i got some troubles to display a pdf using pdfium using c#. I read this other question:
Read a stored PDF from memory stream
i downloaded the pdfiumViewer package, but when i compile it, it says that it can't find the pdfium library. So, I downloaded the package "pdfium.net SDK" so it's working but it's not free, it's limited version. what i was wondering is : do we must have the package "pdfium.net SDK" to have the "pdfiumViewer" working" ?
thx !
The SDK you found, which I guess is Patagames's Pdfium.Net SDK, which is indeed a paid solution.
PdfiumViewer is free, but you have to have pdfium built, which is pretty thoroughly documented.
Pdfium.dll is already integrated into PdfiumViewer. But for it to be loaded, you need when building your project, to copy this file next to your application, either in the root or the x86 or x64 sub directory. The easiest way to accomplish this is by changing the properties of that file, changing the Copy to Output Directory setting to Copy always.
Try the NuGet package "PdfiumViewer". Works like a charm!
In my case*, I needed the NuGet Package PdfiumViewer.Native.x86.v8-xfa, which adds the needed DLL.
Got it running after 10 minutes with this code.
*) Visual Studio 2019 Pro, Windows 10 x64 Pro
I've created my first setup project using Visual Studio 2010. I've noticed that when I build the setup project it generates an MSI installer file and a setup.exe executable. However, I seem to be able to just right click on the MSI file and choose install to install my application rather than running setup.exe.
Does the setup.exe file that is generated do anything other than just fire up the MSI file? When distributing my application can I just provide the MSI file rather than the MSI file and the setup.exe file?
Kristopher Johnson is correct about the older machines, but it also does something else. When you are setting up the installer you can set dependencies and locations to download those dependencies. The Setup.exe does those dependency checks and launches the other MSI files in to install them. This is most often used to make sure Windows has the correct version of .NET or the C++ runtime installed.
If you do not have dependencies and you can guarantee .NET or the C++ runtime is installed then you do not need to distribute the setup.exe file.
Many (most?) users are accustomed to running the "SETUP" program to install something. That's why it's there. It's a good idea to provide it, unless you are certain that only technically knowledgeable users will be installing your application.
SETUP.EXE is also useful if somebody tries to install on an older version of Windows which doesn't have support for MSI files. In that case, it displays some sort of "You cannot install this program on this version of Windows" error message.
I believe (but could be mistaken) that it performs boot-strapping of the correct version of MSI.