Back then when I had Visual Studio 2011 installed, there was a "ClickOnce deployment" option in the project properties window that created self-extracting installation packages that also verified application dependencies (DirectX, ...). I have updated to VS2012 and switched to Monogame due to Microsoft cancelling any further XNA development. That also caused the "ClickOnce" deployment tab to be gone. Nobody I send the Release directory to (it includes some but apparently not all required libraries) can't get the game started - it always crashes, usually due to lack of some OpenAL DLL. Could you provide me with links and/or instructions on Monogame apps deployment/publishing? I've already tried Google but maybe I've overseen something.
I'm targetting Windows.
I found this article while googling for "Monogame Required Dlls":
http://xnameetingpoint.weebly.com/monogameintro.html
Basically, besides the assemblies in your Release folder the user would need to have OpenGL drivers installed.
Related
I have written a Xamarin.Forms application and now I want to deploy the UWP project to the store but I can't create app packages.
When using Microsoft.NetCore.UniversalWindowsPlatform 6.2.2 or 6.2.0-preview I
in release mode, I constantly get this error :
Payload contains two or more files with the same destination path 'System.Runtime.CompilerServices.Unsafe.dll'. Source files:
C:\Users\john.nuget\packages\runtime.win10-x86-aot.microsoft.netcore.universalwindowsplatform\6.2.0-preview1-26926-04\runtimes\win10-x86-aot\lib\uap10.0.15138\System.Runtime.CompilerServices.Unsafe.dll
C:\Users\john.nuget\packages\system.runtime.compilerservices.unsafe\4.5.0\lib\netstandard2.0\System.Runtime.CompilerServices.Unsafe.dll OfflineCurrencyConverter.UWP
But I followed the answer to this GitHub issue saying I should downgrade the package to 6.1.9.
Doing this causes my application to build for ever... the build never stops.
But when I disable .NET Native Tool chain, it builds and run in release mode but packages can't still be created. Please does anyone have a solution ? I'm frustrated.
I feel wasted building a whole app and realizing it can't be packaged at the end for this UWP project.
If it took way longer than you expected to build in release mode, use nuget version of .net native by installing Microsoft.Net.Native.Compiler package on nuget in your project and re-build it as usual. This solution solves the very same problem you have now in my experience.
Building app for .NET Native in release mode can take a very long time. It can even take as much as 10 minutes for larger apps. So make sure to give the compiler the time it needs. It might seem it is building forever, but it should definitely finish.
I've created an office add in using Visual Studio 2015. The add in works perfectly with MSProject in debug mode.
I've published the add in following the instructions here. So far so good.
Now I'd like to release it to the Microsoft Windows Store. I've logged into the Seller Dashboard and I pretty much fall at the first hurdle.
It asks for the app package manifest file. TBH I'm not sure which file it wants exactly, so I tried
xxx.OfficeAddin.vsto file in the root of the "publish" directory
xxx.OfficeAddin.dll.manifest in the publish/Application Files/xxx.OfficeAddin_1_0_0_2 directory
xxx.OfficeAddin.vsto
also within the publish/Application Files/xxx.OfficeAddin_1_0_0_2
directory
I assume it wants No2 but it didn't work so I tried them all. None of them work and all result in the same error:
Your manifest does not reference any supported Office Add-in namespace. The most recent version is http://schemas.microsoft.com/office/appforoffice/1.1.Learn More
Googling this error in quotes returns nothing, without quote - a load of unrelated results.
I'm completely stumped now - has anyone managed to do this?
You cannot add VSTO desktop applications to the Windows store, but may be able to do so soon.
The Windows Store was designed for installing applications that would run in private sandboxes that would keep apps isolated (in case of issues) from your operating system and other applications. However, Desktop applications often have registry entries, dll dependencies, and other client-side requirements. Because the Windows Store cannot accommodate these OS-related and client-side requirements, desktop applications cannot currently be distributed via the Windows Store
Fortunately, Microsoft is finally addressing this issue. They are in the process of finalizing Project Centennial, which will allow one to convert desktop apps for distribution via the Windows Store. It does this by providing a separate registry for desktop apps and a way for dlls to function without hurting other applications.
As of this writing, Microsoft has withdrawn the preview version of their Project Centennial Desktop App Converter. I am hoping this is in preparation for releasing a stable version.
Will Project Centennial allow VSTO add-ins to be sold via the Windows Store? I am hopeful, but this is not certain. We should know more within the next couple of months, if not sooner.
Update: June 8, 2016
At Microsoft's dotnetConf 2016 John Sheehan stated that VSTO add-ins would not be supported in version 1 of Project Centennial. He added that plug-ins (his term) that leveraged other desktop technologies would be able to be converted by the Project Centennial Desktop App Converter some time after Project Centennial's initial release (now slated to be concurrent with Window 10's 1st anniversary release in July 2016). Mr. Sheehan did not elaborate on whether VSTO add-ins would specifically work with later versions of Project Centennial, but he did indicate that compatibility with software that leverages other desktop technologies is definitely on the Project Centennial road map.
I just installed Visual Studio 2015 Community on my computer. Until now I have been using Visual Studio 2010 Professional. Now when I try to run my MVC apps in the build in web server, I get the following error message.
The procedure entry point __CrtGetFileInformationByHandleEx could not be located in \WINDOWS\SYSTEM32\msvcp120_clr0400.dll
I get the same error message if I try to execute vbc.exe (the Visual Basic compiler) on directly at the command prompt. My MVC app also shows a YSOD with
Compilation Error - Compiler Error Message: The compiler failed with error code -1073741511.
How can I fix my VS so I can run my programs again?!
Steps I've tried
Uninstall VS 2015 Community
Uninstall and reinstall .NET 4.6 and .NET 4.5.2
DISM /Online /Cleanup-Image /RestoreHealth
The .NET Repair Tool
Run sfc /scannow
Manually rename the msvcr120_clr0400.dll file to msvcr120_clr0400.dll.corrupt and do 1-5
Uninstall and reinstall VS 2010 w/ SP1
sfc /scannow successfully replaced the msvcr120_clr0400.dll file, but it replaced it with the exact same CTP file as before!
EDIT:
The problem dll's from my system are available for download here:
32 bit
64 bit
32 bit msvcr
64 bit msvcr
Microsoft is aware of this issue with KB3098779 and 3097997:
https://support.microsoft.com/en-us/kb/3118750
The recommendation is to uninstall these patches and then rescan for updates. Newer versions of these security patches (that do not break the VB compiler) are now available.
Okay, I see it from the files you uploaded to the sharing service, your .NET install is corrupted. A standard DLL Hell problem, your c:\windows\syswow64\msvcr120_clr400.dll file is the wrong version. Something you can see when you use Explorer and navigate to the file. Right-click and select Properties, look at the Details tab.
Note the word "CTP" in the Product name, means "Community Technology Preview". A Microsoft term that means "beta version". Clearly you should not be having the VS2013 beta on your machine. Your msvcp120_clr0400.dll is correct, it is file version 12.0.52512.0. It depends on an exported function in the msvcr DLL that the CTP version did not yet have.
Exactly how this happened is always hard to reverse-engineer. You are the 3rd SO user that I know of that had this problem this week, a bit too much of a coincidence. Two basic scenarios, if you ever had the VS2013 CTP edition installed on the machine then the problem is that it didn't get updated like it should have. Otherwise a very typical problem with CTP editions, they are pretty dangerous because the uninstaller is always the last thing Microsoft gets right. And the problem was just never detected until you started using a program that required this export.
Or it was caused by a rogue installer, copying the old version onto your machine without checking the version number. Much less likely, installers never have a good reason to install this particular file since it is only ever used by the .NET Framework. My money is therefore on your machine getting corrupted by the CTP.
You need to solve this by getting your machine fixed. Not that easy, you can never be sure how many other bad DLLs are lying around from such a bad CTP uninstall. A shortcut is copying this particular DLL from a good machine. But best to get .NET 4.6 re-installed.
EDIT from OP:
This answer correctly identified the problem files but reinstalling (or any other common steps) didn't solve it. In the end I copied "good" files from another computer with the version number 12.0.20806.33440.
KB3098779 appears to be the culprit on our server. That is the patch that installed the rogue CTP msvcr120_clr0400.dll mentioned in the above answer.
Solution: we reversed out the patch set that applied KB3098779, and everything is working again.
FYI: this is a .NET framework 4+ issue, not Visual Studio. Our server is a standard 2012 IIS server: Visual Studio is not installed.
I had the same issue on Windows 8.1 although KB3098779 and 3097997 were not installed on my machine. Probably it happened after installation of ASP.Net 5.
The issue was that I had both mcvcr files in version 12.0.51670.34230 while mcvcp files were already in 12.00.52512.0. It was enough to copy both mcvcr files (from System32 and SysWOW64) in this version from my colleague's pc.
If you have problems with permissions set to TrustedInstaller on these file, you can run this powershell command and then change permissions as Administrator:
takeown /A /F C:\windows\syswow64\msvcr120_clr0400.dll
Microsoft have issued a notice on this.
https://support.microsoft.com/en-us/kb/3118750
As others have pointed out too many people in too short a time to be a coincidence. Not a VS issue, this is to do with a bad update from Microsoft.
The info from MS mentions two security patches (KB3098779 and KB3097997).
I have uninstalled only KB3098779 and my site is up was up and running. It required a machine restart to complete
KB3097997 uninstalled without a restart. I maybe didn't need to uninstall but seems sensible given it is also subject to the same notice from MS.
Right now I'm developing a Windows Mobile 6.0 application. When I want to test the user interface, I deploy the application from Visual Studio 2008 to the emulator or a physical device. Unfortunately the deployment is really slow, because the IDE is installing some dependencies on each launch again.
Is there a way to avoid this somehow?
As it turned out, this is happening, because the referenced version of System.Data.SqlServerCe is different to the version on the device or in the emulator, which came with the Compact Framework. To solve this problem is just removed and added again the reference to the System.Data.SqlServerCe library.
I've found this solution here:
http://social.msdn.microsoft.com/Forums/en-US/68e8d920-edd5-4aab-aa4f-ba0bfcf42d26/vs2008-how-to-stop-sqlce-cab-from-deploying-on-every-debug-session
I come to you because I'm desperate. I've developed a GTK# application in C# with the latest MonoDevelop. It's built for .NET framework 4.0 / x86, and the only external library it uses is the official Mysql .Net connector. It's meant to run under Windows XP.
It's the first application I make with this IDE. I was very happy with the results and the development time, but the deployment is a real headache.
It works perfectly on the development machine. The debug is clean. Everything's okay.
Then, as I couldn't find any information about the deployment, I installed a clean XP to try it and see what do I should install on the client's machine.
I've installed the SP3, .NET 4.0 and copied the release package with all the DLLs mentioned in the build log (that made it work outside the MonoDevelop in the development machine). But I'm getting a "the application has encountered a problem and needs to close" error, with no exception, in kernel32.dll, offset 0012aeb.
I've tried to install the .NET 3.5 before the 4.0, updated IE (just in case...), copied more GTK# and Monodevelop DLLs to the exe's folder, installed the Mysql .NET connector, installed Mono 2.8... But nothing. Still getting that unexplained error.
Google and StackOverflow searches didn't help me. I've researched and tried a lot of things in the last twelve hours or more without moving from this machine.
Do you have any advice? What can be causing it? Is there any way to debug the exe (without installing VS...)? Does anyone know what are all the dependencies of this kind of executable?
WinDbg can help you figuring some JIT trouble...
Even though it aint intuitive and require skills, Worth a try. might pop something up.
If it's meant to run under Windows, then you should probably compile it with the Visual C# compiler.
However, more related to your problem - get a debugger in your deployment machine and run the application on it. This is the best way to figure out the problem because we really can't guess it.
Mono Application Deployment Guidelines
There are several options to installing Visual Studio on your production machine, one of them is the Remote Debugging Monitor. It does not require a Visual Studio installation. You can copy the files from your development machine to your server. I've got them under C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger.
You can also use it for Remote Debugging of a Project Built Locally.