Compiling Windows Form app created in VS2017 using VBC.exe? - vb.net

I need to be able to program from Visual Studio but also from a usb key on computers without admin access.
To reach this goal I have used the following tutorials
VB.Net Programming Using Notepad And Command Prompt (Part I)
Tutorial(VB.Net) Creating Windows Form App Using Notepad+CommandPrompt
Now this works great without only one issue, it is hard to edit with visual studio. Intellisense doesn't work too good due to lacking files such as App.config and whatever is in the "My Project" subfolder.
So I decided to instead try to start from a VS2017 project and compile that using only vbc.exe and resgen.exe
Here is my attempt so far.
First I created a new project.
I chose a Windows Form project although the application I want to make will probably start in a "Sub Main" and run an "ApplicationContext" class instead of a form. I tried Console Application, however I find the console window annoying. I can hide the console window easily but it still flashes on startup. WPF looks too new and hard to use for now. A Windows Service might requite admin privileges to run and I'm not sure what an empty project really is.
So I create a Windows Form project
Next up I made the first two changes
I disabled the application framework.
It does something about the My namespace. It makes manual compiling much harder for some reasons. Also I changed the target .net framework to version 4.
This version is because I mostly find version "v4.0.30319" of the .net framework is installed so later version might not work.
Now, I save all that and try to build. An empty form window appears, this works so far from within visual studio at least.
For compiling I have a rudimentary .bat script.
I copy the freely available resgen.exe file to the "My Project" folder.
The code from compile.bat
path=%path%;c:\windows\microsoft.net\framework\v4.0.30319
cd "My Project"
resgen /compile Resources.resx,..\bin\debug\Resources.resources
cd ..
VBC /OUT:bin\Debug\app.exe /resource:"bin\debug\*.resources" /imports:System.Data,System.Deployment,System.Drawing,System.Windows.Forms,System.Xml,System.Xml.Linq,System.Data.DataSetExtensions,System.Collections,System.Collections.Generic,System.Data,System.Drawing,System.Diagnostics,System.Windows.Forms,System.Linq,System.Xml.Linq,System.Threading.Tasks /T:exe *.vb "My Project\*.vb"
pause
Some explanations,
First running this script with recompile the resource file and then compile the executable.
It will include all of the *.vb files as well as the resource file.
The following files are ignored so far
App.config
WindowsApp2.vbproj
My Project\Application.myapp
My Project\Settings.settings
Now the long list of imports is from the vbproj file.
It does not currently updates itself when you add more references in visual studio. A future version of this bat file will be made using vbscript and should extract and auto-add the imports/reference but not there yet.
Now what happens when you run this ?
It does not work with 3 errors as follows :
First it does not respect the defined startup object
This object is defined in the .vbproj file as follows
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<StartupObject>WindowsApp2.Form1</StartupObject>
</PropertyGroup>
</Project>
This section is not taken into account by vbc.exe yet so it appears to default to using a Sub Main and gives this first error.
vbc : error BC30420: 'Sub Main' was not found in 'app'.
Second and third errors as follows
C:\defaultpath\Visual Studio 2017\Projects\WindowsApp2\WindowsApp2\My
Project\Settings.Designer.vb(67) : error BC30002: Type 'WindowsApp2.My.MySetting
s' is not defined.
Friend ReadOnly Property Settings() As Global.WindowsApp2.My.MySettings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\defaultpath\Visual Studio 2017\Projects\WindowsApp2\WindowsApp2\My
Project\Settings.Designer.vb(69) : error BC30456: 'WindowsApp2' is not a member
of '<Default>'.
Return Global.WindowsApp2.My.MySettings.Default
Both of these errors are related somehow to the Root Namespace configuration
This is declared in the .vbproj file but not currently taken into account by the compile.bat file
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<RootNamespace>WindowsApp2</RootNamespace>
</PropertyGroup>
</Project>
In the document Visual Basic Compiler Options Listed Alphabetically
The option /rootnamespace is defined to "Specifies a namespace for all type declarations."
So I add the /rootnamespace:WindowsApp2 to my compile.bat file and both previous issues listed above are solved.
Lastly, to fix the Sub Main issue and instead use "WindowsApp2.Form1" as defined in the .vbproj file
The /main command seems to fit the bill for this, so I add /main:WindowsApp2.Form1 to the command line.
Following some last minute changes to .resource file handling here is the latest compile.bat
path=%path%;c:\windows\microsoft.net\framework\v4.0.30319
cd "My Project"
resgen Resources.resx
cd ..
VBC /OUT:bin\Debug\app.exe /main:WindowsApp2.Form1 /rootnamespace:WindowsApp2 /resource:"My Project\*.resources" /imports:System.Data,System.Deployment,System.Drawing,System.Windows.Forms,System.Xml,System.Xml.Linq,System.Data.DataSetExtensions,System.Collections,System.Collections.Generic,System.Data,System.Drawing,System.Diagnostics,System.Windows.Forms,System.Linq,System.Xml.Linq,System.Threading.Tasks /T:exe *.vb "My Project\*.vb"
pause
This compiles an executable without errors.
I run it and Form1 appears, unfortunately the Console window also appears !
So it seems I still have a Console App and not a Windows Form App
This is resolved by modifying the /T parameter defined as /target from exe to winexe
Final compile.bat
path=%path%;c:\windows\microsoft.net\framework\v4.0.30319
cd "My Project"
resgen Resources.resx
cd ..
VBC /OUT:bin\Debug\app.exe /main:WindowsApp2.Form1 /rootnamespace:WindowsApp2 /resource:"My Project\Resources.resources" /imports:System.Data,System.Deployment,System.Drawing,System.Windows.Forms,System.Xml,System.Xml.Linq,System.Data.DataSetExtensions,System.Collections,System.Collections.Generic,System.Data,System.Drawing,System.Diagnostics,System.Windows.Forms,System.Linq,System.Xml.Linq,System.Threading.Tasks /T:winexe *.vb "My Project\*.vb"
pause
If anyone has any comments or suggestions I would gladly hear them.
I started writing this as a question but I resolved my issues in the course of writing this question.
If there is an easier way to do this please let me know.
In the mean time I hope this can be useful to someone else on the same path as I.
Bye !

Related

Build error when signing with snk key

Build error is occurring since using Visual Studio 2015. When building in Visual Studio 2015 this is occurring rarely. When building in TeamCity this occurs very often.
[Error in Visual Studio 2015]
Error extracting public key from file 'CompanyName.snk': The process cannot access the file 'C:\Users\UserName\AppData\Local\Temp\tmp2FF6.tmp' because it is being used by another process. CompanyName.Project.DAL D:\Projecten\CompanyName\Repository\Source\Components\CompanyName.Project.DAL\vbc
http://i.stack.imgur.com/hKbbe.png
[Error in TeamCity]
CSC error CS7027: Error signing output with public key from file 'CompanyName.snk' -- The process cannot access the file 'C:\BuildAgents\Gamma\temp\buildTmp\tmpD91D.tmp' because it is being used by another process.
http://i.stack.imgur.com/rbgHx.png
I know it's been a while since this was asked but as I use SO for my own reference and I had this problem too I wanted to share my solution.
.snk files are for signing a project. You might need to make a new one.
Right click on your project, select properties.
Click on Signing.
Click the checkbox beside "Sign the assembly".
On the dropdown labelled "Choose a strong name key file" click new.
Fill in the dialog box as you wish noting particularly the Key file name. When you press ok, this will generate a new .snk file.
Save the project and rebuild.
This will use the new .snk in your project and will resolve the
error.
Hope this helps.
Try to clean up the temp folder that is used by the build.
I have seen different types of problems when the temp folder has lots of files.
Some of the tools are using GetTempFileName and they will get errors when temp has a lots of files
The GetTempFileName method will raise an IOException if it is used to create more than 65535 files without deleting previous temporary files.
This is probably an instance of this issue with Roslyn compiler. The workaround would be adding
<UseSharedCompilation>False</UseSharedCompilation>
under any <PropertyGroup> node in .csproj file.
It started for me when I moved the Resharper Cache to System Temp. When I moved it back to the Solution folder, the problem went away, and I could build again.
I just had the same problem. In Visual Studio 2015, I fixed it using the following steps:
Go to Tools > Options
From the Options dialog, select "Projects and Solutions > Build and Run"
Set the "maximum number of parallel project builds" to 1
+1 to #stukselbax for getting me on the right track
Also got help from this link
I used '/m:1' as an msbuild argument, and 'SignPublic' property to true in the csproj file.
Just had this issue today in visual Studio 2022- I was messing with the csproj file and ended up having the wrong filepath to the snk file. I fixed it by changing the filepath to be correct.
Right-click on the project -> unload (so that you can edit the csproj file)
Under <PropertyGroup> check the <AssemblyOriginatorKeyFile> tag
My code was:<SignAssembly>true</SignAssembly> <AssemblyOriginatorKeyFile>../NAMEHERE.snk</AssemblyOriginatorKeyFile> NAMEHERE was specific to my project, yours will vary. Look at your snk file. The ../ in front will vary, check the filepath of your snk file. If you caused this error by messing with your csproj file, like I did, then the correct answer is what the filepath was before you changed it. :)
Right-click on the project -> reload

Can Orchard 1.8.x be installed on a build server that does not have Visual Studio Installed?

I also asked this question on the Orchard forum but no joy there yet. So here it is again...
https://orchard.codeplex.com/discussions/569444 Please read for a few more details.
IF the .NET 4/4.5 SDK came with a developer command prompt (like previous SDKs) then I would not be asking this question.
But since Orchard is build with .NET 4.5 I am getting build errors using the old SDK. It seems that my only option is to install Visual Studio Express on the build server.
I am doing that as we speak so at this point the question is purely academic but I am still curious.
EDIT
STILL NO JOY. Even after installing VS 2013 Express Web the vcvarsall.bat that usually configure the build environment is still not present. So this is no longer a curiosity question. The Express edition also cannot create my build environment. Help.
Seth
Here is my answer...copied and pasted from the forum.
This is a late answer. Bottom line is that I did eventually get our build server to build orchard projects. I am not sure if this is a complete answer or not as I should have answered as soon as I had it done. But I pretty sure this will work.
One other thing to note...It is quite possible that not all of these steps are required. I tried a lot of different things and it might be in the end some of the steps were not needed. It might also reflect a problem on our build server...especially the fact that I had to manually add registry entries.
But here it is without details.
Install the .NET Framework SDK for Windows 7.1.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Install the .NET 4.5 Full
http://www.microsoft.com/en-us/download/details.aspx?id=30653
Install Visual Studio 2013 Express for Web
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
Install the Visual Studio 2013 Build Tools
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
Finally, even after that...it didn't work until I added the following registry keys. I would attach the .reg file but I don't see how.
Save the lines between the lines into a fixBuild.reg file. Then double click...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VC7]
"FrameworkDir32"="C:\Windows\Microsoft.NET\Framework\"
"FrameworkDir64"="C:\Windows\Microsoft.NET\Framework64"
"11.0"="C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\"
"FrameworkVer32"="v4.0.30319"
"FrameworkVer64"="v4.0.30319"
"12.0"="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\"
Finally, to actually do the build, I created a batch file that does the build.
Save the lines between the lines into a doBuild.cmd file. Be sure to place this in the root of the source download...then double click to build...
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat"
msbuild /t:FastBuild Orchard.proj
The first line gets your environment ready. The second build the project using the FastBuild target in the Orchard.proj file. You can read that file if you want to try other build targets.
******* EDIT
There is one thing I forgot to mention. And that is that one thing you have to do to get this to work is that you have to edit some CSPROJ files because the command line build fails with errors like these...
\Orchard\src\Orchard.Web\Modules\CKEditor\CKEditor.csproj(337,6): error : "None" element name for include "Placement.info" should be "Content".
\Orchard\src\Orchard.Web\Modules\Orchard.Tokens\Tests\Orchard.Tokens.Tests.csproj(82,6): error : "None" element name for include "app.config" sh
\Orchard\src\Orchard.Web\Modules\TinyMceDeluxe\TinyMceDeluxe.csproj(377,6): error : "None" element name for include "app.config" should be "Cont
\Orchard\src\Orchard.Web\Modules\Upgrade\Upgrade.csproj(156,6): error : "None" element name for include "app.config" should be "Content". [C:\Us
\Orchard\src\Orchard.Web\Themes\Themes.csproj(280,6): error : "None" element name for include "Upward\Views\Content-Story.Detail.cshtml" should
The fix is to do exactly what the error indicates. Open the csproj files and search/replace "
Also, some of the projects reference app.config files that do not exist in source. You also have to remove those references. I usually just delete the content node entirely or the group entirely.
Seth

The OutputPath property is not set for project

Building my Jenkins/MSBuild solution gives me this error
c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(483,9): error :
The OutputPath property is not set for project '<projectname>.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Latest' Platform='AnyCPU'. You may be seeing this
message because you are trying to build a project without a solution file, and have
specified a non-default Configuration or Platform that doesn't exist for this project.
[C:\<path>\<projectname>.csproj]
Any ideas?
EDIT
I have this in my .csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Latest|AnyCPU'">
<OutputPath>bin\Latest\</OutputPath>
</PropertyGroup>
I have figured out how it works (without changing sln/csproj properties in VS2013/2015).
if you want to build .sln file:
/p:ConfigurationPlatforms=Release /p:Platform="Any CPU"
if you want to build .csproj file:
/p:Configuration=Release /p:Platform=AnyCPU
notice the "Any CPU" vs AnyCPU
check the code analysis, fxcop, test coverage(NCover) targets, as well as the MSBUILD should be located properly. In my case its:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319
but it can be different as you can see microsoft has given 6 cmd options to build code base::AMD (with cross plt, x86 & x64 options) and Windows(cross, x86, x64) and that also when code development happened with default JIT (it can be PreJIT ngen.exe, econoJIT)
I think more than this troubleshooting can be handle using power shell + msbuild. May be helpful for someone ...
Open up your csproj in a text editor and see if you have a property group section, should look something like this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Latest|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Latest\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
Do you have a 'Latest' build configuration? If not add the above section to the csproj.
As mentioned by perlyking, rather than editing the csproj XML The following worked for me. Here are the steps I used.
Open the Project Properties.
Select the Build Tab.
Under the Output section, Check that an output path is set. (if not set one, save the project and it should work).
If it is set, click on the "Browse..." button of the output path.
When the folder selection dialog opens, Navigate up one level in the
file browser and then re-select the output folder and click
the "Select Folder" button.
Save the project properties and it should work.
To add to what #James said, I found that if I looked at the project Compile properties in VS2013, the Build Output Path was specified. But when I examined the .csproj file directly, the OutputPath element was missing for the relevant build configuration. So in VS I simply made and reversed a minor edit to the output path, saved it, and that kicked the value into the project file, and I was then able to build.
I was using MSBuild to build multiple .sln files, and had added a new step to build a .csproj file as well, when I encountered this error.
#Saurabh's answer highlighted the root of the problem. However, when fixing it, adding /p:Platform=AnyCPU to the MSBuild Arguments section didn't fix it. I actually needed to update the Platform value on the build step.
All other build steps were using the $(BuildPlatform) variable value (which happened to be "any cpu", with a space in it).
(Had I been building multiple .csproj files, I probably would have created a second variable for the AnyCPU platform.)
For me the answer was to fix all the projects in Build > Configuration Manager.
If you have some projects where the name or platform does not match the solution configuration, you should change it so they all match.
I was running into this issue while updating an older project with additional project configurations for per-environment config transforms.
It turns out that when the project configurations were added to the csproj file, they were inserted after an Import element which caused the issue.
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'ProjectName.Dev|AnyCPU'">
...
Moving the Import element after all the PropertyGroup definitions fixed the problem for me.
Relevant similar case: https://stackoverflow.com/a/31072208/2452820
I got this error only when I was publishing my web project. I had mistakenly selected the wrong build configuration when setting up the publish profile.
I had same issue. I have updated my windows platform by using command line. Currently i got updated to windows#5.0.0 version. Then you need to search for file name "SQLite3.UWP.vcxproj". Try to change "v141" to "v140". Currently I am using Visual Studio 2015 professional. If it's Visual Studio 2017, then there is no need to change version in SQLite3.UWP.vcxproj file.
In my case this error happened because the output folder included a dot to make it relative to the current directory. The problem was solved by removing the dot.
The offending Build output path was:
.\bin\Output
The problem was solved by changing it to
bin\Output
The build output path can be found in the Build tab of the project properties, and there is a different path for each combination of Configuration and Platform.
Just had the issue for some service fabric stuff in MSBuild.
First step was right clicking each affected project and pulling up their Properties, selecting the Build tab, then setting the platform target to x64.
Second step was to go into the configuration manager and set each project to also use x64 for Debug and Release.
This was for a VS2017 project.
I had the same problem on a few projects. After adding a new configuration to the projects, the PropertyGroup was added at the very end of the Project file.
Moving the PropertyGroup to right after all the other configurations PropertyGroup fixed the issue.
I hope this helps.
I had this witha slightly unusual SLN/CSPROJ file arrangement:
I had project files:
A.csproj, with configurations "Dev" and "Production"
B.csproj, with configurations "Dev" and "Production"
C.csproj, a "common" library used by both A and B with configurations "Dev" and "Production"
And I had SLN files:
AC.sln, with configuration "Production" - this is used by jenkins to build project A and the common library
BC.sln, with configuration "Production" - this is used by jenkins to build project B and the common library
ABC.sln, with configuration "Dev" - this is used by developers in VS to write new code without having to keep opening different solutions (this answer is a simplified view of a 55-project solution)
I'd made an edit to the common library and introduced a dependency on project A. AC.sln would still build in jenkins but BC.sln gave an error saying:
The OutputPath property is not set for project 'A.csproj'. Please check to
make sure that you have specified a valid combination of Configuration and Platform
for this project. Configuration='Debug' Platform='AnyCPU'.
It was initially puzzling because we don't even have a Debug config anywhere in any project; find in files for Debug| turned up 0 hits
ABC.sln that the human developers use in VS would also build fine. Building BC.sln gave an error that A.dll wasn't found
When the circular irresolvable problem of C depending on A was removed, everything started working again
This error is misleading and can be caused by a different issue. Check the entire message:
The OutputPath property is not set for project 'myproject'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='myconfig' Platform='AnyCPU'. This error may also appear if some other project is trying to follow a project-to-project reference to this project, this project has been unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform.
My build configuration was missing this node in the csproj:
<PlatformTarget>AnyCPU</PlatformTarget>
Despite saying AnyCPU was the selected Platform in the dropdown, the actual xml was not there. Adding it fixed the mismatch between the project and the other project it was referencing.
The OutputPath property is not set for project error message will appear if a Platform environment variable exists (as seems to happen on HP laptops) and the target of MSBuild contains a reference to another Visual Studio project.
After renaming the Platform environment variable my build now works.
It seems the parameter /p:Platform="Any CPU" gets applied to the target solution but doesn't 'carryover' to referenced projects. In my instance, the error message indicated referenced projects were using the environment variable Platform=MCD.
I had two project configs, Debug and Release. When the Release build was used, it was throwing this error. The issue I found was that in the csproj file, the Debug config was near the top and the Release config was all the way at the bottom.
Manually moving the Release build just below the Debug build fixed it.
I'm assuming I did something incorrectly when setting up my build configurations because this doesn't feel like something I should have had to manually adjust.
Edit the properties of the project:
Make sure "Configuration Properties->General->Output Directory" is not blank. Note, it's not called OutputPath here. You can probably copy the value from Intermediate Directory.
I encountered the same problems when build TheXTech (https://github.com/Wohlstand/TheXTech/wiki/Building-on-Windows#building-in-visual-studio-201520172019-and-cmake) recently. And finally I found it is a cmake -A issue. The correct arch for 64 bit on windows is x64, not Win64.
For some more reference, see https://cmake.org/cmake/help/v3.16/generator/Visual%20Studio%2016%202019.html#platform-selection, https://cmake.org/pipermail/cmake/2019-April/069379.html.
Go to Solution properties and change the configuration to Any CPU or X64 or X86, and if build is checked uncheck that for what you are getting error for. By default, project build that for build configuration in solution and throw error as mentioned when building the project.

allowDefinition='MachineToApplication' msbuild error

We have a ASP.NET MVC with 4-5 different build configurations. Whenever we change the build configuration, we need to delete the obj folder for the web project, since we get the 'allowDefinition='MachineToApplication' error. A pain, but we managed by deleting the folder in pre/post build events.
Now I need to configure our CI to build deployment packages. This means that I cannot delete the obj folder. Every time I compile e.g. with the following msbuild parameters
/p:CreatePackageOnPublish=true /p:DeployOnBuild=true
I recieve the error:
web.config(123): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
As far as I understand, the problem is that there's multiple .config files in the project - In our case, there's not. I could really use some help to find an explanation and find a permanent (no- hack) fix.
Edit:
This question is marked as a duplicate, but the corresponding answers and cause(s) in the 2 threads, are clearly different from each other. Not sure what is intended with this tag - I've read that particular post before posting this question, as it didn't answer my question. There's multiple causes for this error message. It is 'similar', but definitely not a duplicate!
There is a similar question here on SO with some good solutions for this issue.
The problem is that building a deployment package creates a copy of the web.config in a subfolder of /obj. That will normally be be cleared out if you do a rebuild or a clean. However, if you build a deployment package in one configuration (e.g. Debug) and then switch to another confguration (e.g. Release) the obj/Debug folder is not cleared out and the web.config file there causes problems.
The quick solution is to clean all configurations and then do a (re)build. Alternatively you could delete the /obj folder in your project.
To permanently resolve the issue you can either move the intermediate output (/obj) out of your project folder or modify the project to force a clean of all configurations on rebuild.
I too was deleting the obj folder until I had a conflict with a build script which required it. Catch-22, I used the accepted answer on the following SO link to move the location of the Obj folder to C:\Temp\BUILD. You have to do it per csproj file, but it is a great solution.
Here is the link: VisualStudio: How to save the obj folder somewhere else
Note that I am using a variable for the project name.
R:\Temp\Build\Debug\$(MSBuildProjectName)
I have the above line in both debug and release sections for all my projects, including class projects. My build path is a ram drive for speed. See this SO for more info: How to access macro variables within csproj file?
I just answered a similar question here. To recap, I ran into this problem in one of our MVC projects, and it was due to having the MvcBuildViews property in the project file set to true. Setting the property to false fixed the problem.
<MvcBuildViews>false</MvcBuildViews>
I also found this answer which outlines an alternative that does not require turning off view building.
I don't know that there is an "official" fix as it just seemed to start on multiple projects of mine for no reason that I can find in Visual Studio Premium 2012 (never happened in previous versions of VS).
As a work around to automate the deletion of the obj directory as others have said, similar to an answer by user Casual in this post VisualStudio: How to save the obj folder somewhere else, where unfortunately just moving the location of the obj folder didn't always seem to work.
Instead I added a few commands under Build Events in the Pre-build event command line:
rd "$(ProjectDir)obj" /S /Q
md "$(ProjectDir)obj"
md "$(ProjectDir)obj\Debug"
md "$(ProjectDir)obj\Release"
You can change/add/remove subfolders to match your custom build configurations using the line where buildConfigName matches the name of the build configuration you are using:
md "$(ProjectDir)obj\buildConfigName"
Hope this helps!
That error indicates that you are trying to something specific to an application at an IIS tree level that isn't defined as an application. For example if you try to do app-level functions in a web.config in a virtual directory, you will get that error. You need to find the path you are deploying to and make sure that it is defined in IIS as an application vs a folder or vdir.
Cleaning the solution (Right click Solution in VS, clean), worked for me.
I had the same error but with a deployed page.. Then realized my webserver's clock was set back to 2010 for some reason. set it to the correct date fix my problem
Clean your project
Remove the /obj folder (probably using publish and deploy? - there is a bug in it)
Althoug the problem is explained and solved in one way in the accepted answer, I wanted to show a solution which can be better for other cases. This solution has been included in some version of VS, but I can only say that I had the problem in VS 2013 Update 5. (See the "Beware" below, it could be fixed in this version, but not working only in my particular case).
I borrowed the soltuion from Error: allowDefinition='MachineToApplication' beyond application level on Visual Studio Connect.
The solution consist in including these lines to the web application project (.csproj file) which handle the deletion of the offedning intermediate files (which wans't a solution for the accepted answer, as he needed those intermediate files):
<!--Deal with http://connect.microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level,
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
</ItemGroup>
<!--Force msbuild to expand all the wildcard characters so to get real file paths-->
<CreateItem Include="#(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
<Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
</CreateItem>
<Delete Files="#(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>
Beware: for some reason, probably because I included it myself in the project, my build target for building the views was named "BuildViews", instead of "MvcBuildViews", so I had to modify the BeforeTargets attribute accordingly.
This is not necessarily the exact same issue, and to be honest, probably down to pure lack of knowledge on my part, however I had this same error when:
I set up a standard asp.net new project actually just used for HTML5 stuff so nothing other than the usual project structure
I then (not thinking perhaps!) added a new WCF REST project (which actually was just another base asp.net project using very good examples from http://www.codeproject.com/Articles/128478/Consuming-WCF-REST-Services-Using-jQuery-AJAX-Call?fid=1597004&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&fr=26#xx0xx and http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
The problem was I added the WCF REST project (#2) as a SUB-DIRECTORY of the main project (#1) and then tried to build! even if I cleaned the project of course.. I also made both projects use IISexpress because I thought there was an issue using the same port or something.
Of course the build process saw the web.config from #1 and then a sub-dir with another web.config #2..
I realise this probably should be a very basic understood gotcha and it has caught me out a while ago, however sometimes it's the simplest of mistakes that are a real pain!
Might help others... who perhaps haven't had their morning coffee..
tip 1: clean & then rebuild.
tip 2: just close VS and open again.
tip 3: the downloaded project may be inside another sub folder... open the folder which has you .net files.
c:/demo1/demo/ (all files)
You should have to open demo from vs... not demo1.
I have a somewhat a similar problem, i had the main config as Copy Always so it copied the config to the bin directory. When i republished the main project, i got the MachineToApplication error. So my solution was to just change the config to Do Not Copy and remove the extra configuration in the bin folder.

Error 'TF215097:...Cannot create unknown type for...' custom CodeActivity [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
TFS 2010 Custom Build Activity TF215097 error
I'm trying to create a CustomActivity to run after each successful build.
I've followed the exact steps of several tutorials
http://blogs.blackmarble.co.uk/blogs/rfennell/archive/2010/03/08/lessons-learnt-building-a-custom-activity-to-run-typemock-isolator-in-vs2010-team-build.aspx
http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx
http://www.dotnetcurry.com/ShowArticle.aspx?ID=522&AspxAutoDetectCookieSupport=1
And all have lead me to the same result - The build fails after several seconds with this error:
TF215097: An error occurred while initializing a build for build definition
\MyCompany\Dev - Client: Cannot create unknown type '{clr-
namespace:BuildTasks.Activities;assembly=BuildTasks}TFSBuildLocalizer'.
I came down to a point where I have removed all custom references I had in the CodeActivity project and commented out all of the code.
I have added the output dll to the TFS, and I have the following post build script in the project's properties:
"$(DevEnvDir)\TF.exe" checkout "$/MyCompany/Development/Djenne/Dev/Tools/BuildProcess/Output/$(TargetFileName)"
copy /Y "$(TargetPath)" "C:\tfs2010\MyCompany\Dev\Tools\BuildProcess\Output\$(TargetFileName)"
"$(DevEnvDir)\TF.exe" checkin "$/MyCompany/Development/Djenne/Dev/Tools/BuildProcess/Output/$(TargetFileName)"
I've made sure that the namespace in the workflow xaml is correct for the custom CodeActivity.
I have no idea what else can I try,
Please help!
Thanks,
EDIT: I'm adding more descriptions about what I've already tried:
The CodeActivity class already have the attribute:
[BuildActivity(HostEnvironmentOption.All)]
The CodeActivity class is contained inside an Activity Library project.
Here is the ProjectTypeGuids tag inside the csproj file:
<ProjectTypeGuids>{32f31d43-81cc-4c15-9de6-3fc5453562b6};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
In the custom workflow xaml I've added my CodeActivity right after "Get Impacted Tests, Index Sources and Publish Symbols"
I currently don'e have any InArgument nor OutArgument in my CodeActivity.
These are the references in my CodeActivity project:
Microsoft.CSharp
Microsoft.TeamFoundation.Build.Client
System
System.Activities
System.Core
System.Data
System.Data.DataSetExtensions
System.Xaml
System.Xml
System.Xml.Linq
WindowsBase
In "Build Controller Properties" I have set the "Version control path to custom assemblies" with the same TFS path as my post build script:
$/MyCompany/Development/Djenne/DEV/Tools/BuildProcess/Output
In my Build Definition I've set "Build process template" with my custom workflow xaml.
Thank you guys for the answers, do you have any more thoughts?
Thanks
Ok, I got this thing figured out.
Here's what worked for me:
I've installed my dll to the GAC in the build server, ran the build and suddenly it worked!
gacutil.exe /i buildtasks
Afterwards, I've uninstalled the dll from the GAC, and it keeps working even still.
gacutil.exe /u buildtasks
Another thing, my project had several references which I also had to checkin in the same directory as the CodeActivity dll itself.
So to do that I've changed my project's post build script:
cd "C:\tfs2010\Djenne\Dev\Tools\BuildProcess\Output\"
"$(DevEnvDir)\TF.exe" checkout "$/TradeNetworks/Development/Djenne/Dev/Tools/BuildProcess/Output/*.*"
xcopy "$(TargetDir)*.*" "C:\tfs2010\Djenne\Dev\Tools\BuildProcess\Output\" /E /R /C /Y
The only thing left to do now is to figure out how to debug this damn thing.
But that's an issue for another question.
Thanks to everybody who helped,
Hope this will help anyone in the future as well.
EDIT:
One more thing I've noticed is every time I edit my custom workflow, it regenerates the xaml and removes the ";assembly=BuildTasks" suffix from the custom CodeActivity namespace (xmlns).
So after every change I need to edit the xaml to fix it over and over again, otherwise the same error reoccurres.
You have to decorate your class with the BuildActivity attribute. See http://www.ewaldhofman.nl/post/2010/05/27/Customize-Team-Build-2010-e28093-Part-7-How-is-the-custom-assembly-found.aspx at the bottom. There is an UPDATE section with more information.
Where is assembly of your CustomActivity? You must add this assembly to source control and introduce it to the Build Controller you are using. For this:
Right click on Builds node.
Select Manage build controllers.
Click properties.
In the "Version control path to custom assemblies" section, introduce your assembly.
I had this exact same problem. The reason was that I had compiled the library with the custom activities against the x86 platform and the Build Controller was running off of a 64-bit Windows 2008 VM. Switching the target platform to AnyCPU allowed the build controller to immediately utilize the library without having to add it to the GAC.
The problem may be related to the output dll being in TFS.
What could happen is the following:
TFS does a get latest
The output dll is fetched and is read only
TFS tries to build
The build tries to write to the dll
Since the dll is read only you get an exception