I have just started using xbuild to compile my C# solutions using Visual Stuido's .sln files. The outcome is two folders: bin and obj placed in the same localization as the .cs files of the project.
Both of them contain folders for Debug and Release versions, and both those versions appear to be the same application when I run them.
Is there any difference between those apps in bin and obj? And if there is, which one is the "complete app" I am "supposed to" run? Or am I missing some flag/option? Which files are necessary for the app to run (if I wanted to move just the executables and would like run them, which ones are necessary?)
I am using OSX (10.10.2), XBuild 12.0 and Mono 3.10.0.0 , if that is necessary.
Thanks in advance.
Long story short:
bin/Release/ are the files you should deploy.
bin/Debug/ are the files you should test in your developer machines.
Files in obj/ are useless, you can remove them.
Related
I have a C# solution with VS 2017, containing an app project, a desktop extension project, and a packaging project. As I mentioned in the answer of this question, I finally get msbuild to create a single bundle with both x86 and x64 for me. However, after I tried to install from that bundle, I found that msbuild actually picked up the wrong package.appxmanifest because they have different version numbers.
So... I have two package.appxmanifest, one in packaging project, and one in my main app project. When I build from the wizard in VS 2017, the one in packaging project will be used, which is correct. When I use msbuild to build with just one platform, it will pick the right one as well, like this:
msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x86
Only when I use msbuild to build two platforms together, it will use the one in my main app project:
msbuild .\MyApp.sln /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64" /p:UapAppxPackageBuildMode=StoreUpload
I also tried to build the packaging project instead of the solution, but because our desktop extension project is only x86, I will get errors about configurations when building x64.
Questions:
Does anyone know why this is happening?
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the platform, which platform is used to build?
Should I add <AppxBundle>Always</AppxBundle> or <AppxBundle>Never</AppxBundle> to the packaging project?
Does anyone know why this is happening?
That because you have two Package.appxmanifest files with same ID in the solution. When you create the App Bundle with .sln, MSBuild/Visual Studio could not to know clearly which Package.appxmanifest should be use.
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the
platform, which platform is used to build?
Not sure the reason why you can not specify the platform. To resolve this issue, you can try yo build the project file .csproj instead of the solution file. For example, when you build the app project, you can use the command line:
msbuild .\MyApp.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64"
And then build the packaging project:
msbuild .\YouPackaging.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86"
Should I add Always or
Never to the packaging project?
If you build the project, no need to add those two properties to the project file, those two properties are used to the solution level and you have a project that you do not want to add to the bundle:
because at the solution level, it’s not clear which app should appear
in the bundle. To resolve this issue, open each project file and add
the following properties at the end of the first
element
Hope this helps.
I have a WinRT app built with VS2013 using C#. It uses SQLite so it needs the sqlite3.dll included in the project to be in the output directory. I included that DLL in my project and set it to always copy to the output directory. The problem is VS2013 copies it to the Debug directory, but not the AppX directory underneath Debug, which appears to be the WinRT output directory. Because of the the app fails because it can't find sqlite3.dll, which is up in the parent Debug directory instead of the AppX directory.
For now I'm just hand-copying the DLL into the AppX directory. What's the best way to fix this problem so that the DLL is copied to the correct directory?
In your project's Properties window choose Build Events tab. On Post-build window include similar string (please, mind to change the path to sqlite3.dll):
xcopy /Y $(ProjectDir)3DParties\sqlite3\$(PlatformName)\sqlite3.dll $(TargetDir)AppX\
Or even better option. This page https://www.sqlite.org/download.html contains section named "Precompiled Binaries for Windows Runtime" where you can download VSIX package. When you install this package into your system, you can simply reference sqlite3.dll for all target platforms (ARM, x86, x64) including all necessities automatically like this: Add Reference -> Windows 8.1 -> Extensions -> SQLite for Windows Runtime (Windows 8.1)
I can't be sure this is the "right" solution, but I set the file's property to Content/Copy-if-newer.
THEN what I've found is that if the AppX directory is already there, VS doesn't update it, just as you describe above, BUT if you delete the Appx directory then VS will create it from scratch and add the necessary files.
Not as good as having everything automated, but beats hand-copying.
I know that visual studio has A LOT of required files to launch anything through an executable, is there a way I could create an .exe that doesn't require all the excess files like you would with a JAR file? I know they are completely different but I'm just trying to find out what we can do other than installing the application on the users PC. Thanks!
is there a way I could create an .exe that doesn't require all the excess files like you would with a JAR file?
Partly. If you're using VB.Net, you will always need to verify that the machine where you run your executable has the .NET Framework version which you target.
Most systems already have some .NET versions installed, which will allow your .exe to "just work" (provided you don't use any libraries apart from the framework). Targeting an older .NET framework (like 3.5) will allow your exe to work on any system with .NET 3.5, without any other files.
I have already built a project, and run it in VS2010.
But if I want to run the .exe on other computers which does not
install Visual Studio, it will need .dll files (such as msvcrt.dll and
msvcp60.dll in WINDOWS\SYSTEM32, and some other dlls in the
development package). I didn't use MFC in this project. How to static
link all these dlls into the .exe file in Visual C++ so that I don't
have to copy all the dlls to the other machines?
BTW: I don't want to make install package either
Thanks
Siba
You can set your project to statically link the CRT, by using the /MT flag for the runtime library. Or, you could keep the /MD setting, and install the vcredist package along with your executable (you can get it from here, and also from one of your VS2010 installation folders). To get an idea of each options pros and cons, read this.
Oh, and a similar question has been asked before...
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.