I just finished a simple project and now I'm moving on to something else. Before that, I need to document how to compile and run the project so that when somebody else (or me in six months) needs to work in it, he'll be able to read how to start.
I installed some visual studio features for the project (eg. IIS Express). Is there a way to get a full list of these, or do I just have to look through installed features and try to remember which do belong to the project?
I am trying to run multiple apps with the same code, the only differences are application names, icons and the splashscreen.
I am already 100 % sure that my approach must be complete crap, but here is my approach:
I copied the excisting project specific configuring files, changed all file names to the new project, replaced references inside these files and imported this project back to the solution, because creating a complete new product within the solutions ignores all yet created files so I wanted to save some time. Now have 1 solution (I thought of this as the product) and 1 projekt for each customer, all targets sharing all code, except the project configs with the ids, names and icons etc..
But when I try to build any of the project I get these errors
Error occurred while restoring NuGet packages:
The process cannot access the file
'C:\...\project.lock.json'
because it is being used by another process.
Or the assembly is used by another application.
So, this can't be the right way to do what I want to do by Visual Studio, I'm looking for the right way to handle 1 base-product but many customer-specific-apps with Visual Studio 2015.
Sadly I couldn't find any tutorial for that yet.
Maybe I'm searching with the wrong description or naming, I thought of projects as targets in Xcode.
A link to a proper tutorial would already do the job for me.
Thanks!
According to your description, I think what you want is building multiple branded apps from a single Visual Studio solution. If so, here is a nice article: Multi-Branded Apps in Visual Studio (Windows 10 UWP) you can refer to.
The key point here is using separate build configurations for each app and then using Pre-build commands to create the app package.
For more info, please see Understanding Build Configurations and Specifying Custom Build Events in Visual Studio.
When I try to create a new Windows Forms project, I get the " ....csproj cannot be opened because its project type (.csproj) is not supported by this version of the application" error. The .csproj file it is referring to is in AppData\Local\temp\randomname\Applicationname.csproj but that file does not actually get created.
I know that when this error crops up with opening projects created in previous versions, it's usually a missing library that is used by that particular project but for the life of me, I cannot figure out what library I could be missing here as it is a new project.
I have VS 2013 Ultimate installed with all components.
Running on Windows 8.1.
First confirm it is not a add-on or a problem with Visual Studio itself.
Try and start Visual Studio from the command line with devenv.exe /resetskippkgs and also try disable any IDE extensions temporarily to see if one of them might be stepping on something. Do these two things first to see if the problem lies with VS IDE. Of course try creating a project after you have done these two things and see if you get the same results.
I never figured out what the actual problem was but I've installed Update 5 which was only released less than two weeks ago and it's working fine now.
I'm working on a WP7 project and noticed that VS constantly checks out WMAppManifest.xml. As far as I can tell this happens regardless of what type of code change I make. Is it possible to prevent this behavior or is it necessary?
Same thing here, the file is checked out every time I build a project and it is not modified. The file is always the same as before. I am using TFS. Looks like a bug.
This appears to be fixed with the latest Mango tools released with the 7712 build.
A lot of people new to CI (Continuous Integration) install VS (Visual Studio) on their CI server "because it is required to compile the code". MSTest is a common reference brought up here.
Why should I not install VS (or generally speaking, any software not out-of-the-box) on my CI server?
(This question has not been asked before apparently, so I'm adding it for reference. If it already exists, sorry, I missed it, please merge. If no answer is provided to this question within some time I can add one myself)
Because you don't need to. A Visual Studio license is pretty expensive, so having one just lying around on a server where no one's using it is just a waste.There are a couple of arguments why you would still need to install a full blown Visual Studio instance on your Continuous Integration server - but here are their counter arguments:
Reason 1: I need it to compile.
Reality: No, you don't. You need MSBuild to compile, but that is available for free, in the Windows SDK. Note that there are several versions for different operative systems and .NET versions, so be careful to download the correct one.
Reason 2: I need it to make quick fixes on the server.
Reality: No, you don't. You shouldn't make quick fixes on the server - you should check out from your version control system, make the fix, build and run tests locally until it works, check in, and have the CI system do the rest for you. That's why you have a CI system.
Reason 3: Without Visual Studio, I can't run MSTest no my CI server.
Reality: Wrong. AFAIK, the MSTest runner is also part of the SDK (at least that's what it seems like on our CI server here - although I can't verify it since we don't have any tests at the moment...). However, a quick googling found this blog post which explains how to do it without the SDK as well. I haven't read through it in detail, so I can't promise that it works, or that it's legal. You have been warned.
Feel free to add more reasons in comments, and I'll counter them.
You might need to install Visual Studio anyway, out of practicality
I was going to try and refute the accepted answer, posted by #TomasLycken, in the comments, but found I needed more space to talk. Even though I technically agree with what #TomasLycken has asserted, here, I'll list some of the dependencies that I found difficult to install on my CI server - and leave it to you to decide how right the accepted answer is...
1 - 'mshtml' primary interop assembly
You can see the problem I was getting in my build output at this S.O. question I created and answered. Mind you, I spent several hours figuring out how get the desired PIA registered - and it was a result of running some .exe's on the server that came from my V.Studio installation - hmmmmmm
CONTEXT: I had a win forms project that used the Web Browser control.. and in the 'WebDocumentCompleted' event, I was casting the DomDocument to hshtml.IHTMLDocument2 .. and that's why I had a reference to Microsoft.mshtml in my project.
RESULT: Now #TomasLycken suggests I deal with this by fixing my code. At first, I wanted to bawk at this suggestion. My code is deployed and working! But, when I do a web search, I see that Microsoft doesn't really recommend using their mshtml PIA outside of the Visual Studio environment they developed it for.
The offending 10 lines of code was effectively doing a little screen-scraping of data on behalf of our users who do research on technical topics in several well-known web portals. But, when I tested this code, written in 2009, it appears that the DOM it once manipulated has now changed in 2016. I know shocking. Probably not my smartest bit of code. Probably time to retire this function - in other words, fix the code and recommit it.
#TomasLyken I think is right on this one.
2 - Win Forms Project post-build script
CONTEXT: So I had come across this cool post-build technique on S.O. that allows my app.config file in my WinForms project to undergo an XDT transform similar to the way my web projects' web.config files are transformed. Well, it just works OOTB, so-to-speak, if you copy from S.O. and into the .csproj or .vbproj source file. But, once you put all this onto a build server with no Visual Studio, the critical piece fails due to a dependency on:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Now this is straightfoward enough to rectify.. I just copied over to the CI server my C:\Program Files (x86)\MSBuild\Microsoft directory. But, should I? Since I've kinda went off the reservation of what Visual Studio normally would support.. one could argue that #TomasLycken's accepted answer is still right on this point, too.
3 - Just getting all the .NET Frameworks and Multi-Targeting Packs in place
Points 1 and 2 above, were actually the last things I conquered in my attempt to get my first build job to run. And my first build job is for a solution stack that I've created and maintained over the past 8 years.. so it has weathered a few frameworks and would have some non-trivial texture to it. I knew it wouldn't be easy. In fact, I hoped by making a CI server that could build this .sln, that it would in fact be ready to build most any other solution we threw at it.
When I first received my clean "Windows 2012 R2" server, it simply had a lot of things missing.. and I'm wondering if I had installed Visual Studio first, if it would have rectified some of these things straight off?
Below is my synopsis of what I had to do - but it doesn't show the pain and suffering involved figuring it all out and the false starts. Maybe it'll help someone else, though.
> First, uninstalled 4.6.1 framework
-- (find Update for Microsoft Windows (KB3102467) and click Uninstall.)
-- also uninstalled anything from MS labeled with C++ redistributable (a later step will restore these)
> Then, install Windows 7 SDK (installs critical "reference assemblies" and a proper baseline 4.0 framework)
-- Then, install Multi-Targeting Pack for Framework 4.0.1 (netfx_401mtpack.exe)
-- Then, install Multi-Targeting Pack for Framework 4.0.3 (netfx_403mtpack.exe)
> Then, reinstalled 4.6.1 framework for 2012 R2 (KB3102467)
> Then, installed Microsoft .NET Framework 4.6.1 Developer Pack (DP461-DevPack-KB3105179-ENU.exe)
> Then, installed "Visual Studio 2015 Build Tools" (BuildTools_Full.exe)
> Downloaded a copy of nuget.exe and put it in the C:\Windows directory
4 - Getting rid of 'missing ruleset' warning MSB3884
From #kevinbosman's post on this GitHub issues thread
If you don't want to edit your Microsoft.CodeAnalysis.Targets file, please note that it is not enough to merely copy the folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server.
You also need to create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\Setup\EDev and add the string value StanDir = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\
5 - Getting MSTest to run correctly
Need dlls copied into your build machine, some must register w/GAC more info here specifically:
Microsoft.VisualStudio.QualityTools.Resource.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Need a hive out of your dev machine's registry copied into build server
some warnings, if you want them to go away, according to this Microsoft visual studio help forum require a VS 2010 and feature pack 2 installation.