We have a semi-complex Visual Studio solution that has a Silverlight 4 front end, CSLA 4.1 for the business entities, and using the CSLA WCF data portal. Because of using CSLA for the serialization across the wire, we have to have our Silverlight business assemblies the same name as our server side business assemblies. The problem comes when trying to build our Web application due to conflicting assembly names. Compiling on a developer's box works fine since Visual Studio is doing it's own magic to avoid conflicts at the solution level, but having separate builds for the Web Application and the Silverlight projects on the build server is causing issues due to the Web Application referencing the Silverlight projects in the .csproj. Due to that, when we have TFS perform a build against the Web Application it will attempt to compile the Silver projects and update the XAPs. We have that being done as a separate build so we don't care about that.
Is it possible to set up the .csproj build a Web Application on a developer's machine with the Silverlight references building, but having them ignored on the build server? Ideally it would involve not relying on our own custom MSBuild properties being thrown at the build in TFS. As a last resort we could stop relying on the .csproj build scripts and create our own MSBuild file, but we don't have the time allocated for that just yet.
The solution I ended up taking was modifying the Web Application .csproj so that the line
<SilverlightApplicationList>...</SilverlightApplicationList>
had a conditional of the following
<SilverlightApplicationList Condition="'$(SilverlightApplicationList)' == ''">...</SilverlightApplicationList>
Then in build definition for the project, under Process -> MSBuild Arguments I added
/p:SilverlightApplicationList=" "
So now developers can build locally and the build process can build just the Web Application without the Silverlight projects.
Related
Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.
Environment: Visual Studio 2010 Premium
Using the MS Unit Test Framework I have many projects in a solution that run fine, either with or without deployment enabled in the testsettings file. One project, when run with deployment DISABLED insists on looking for files in the deployment directory and consequently fails since the context is without deployment. I cannot find where or how VS has decided for this 1 project (out of many) it should be using a deployment directory (i.e. TestResults/......
Can any one suggest how to get VS to make this project behave just like all others in the solution. Also, no class attributes for deployment items are in use for this set of test classes.
I have Downloaded demo project from here
I tried to run Silverlight project SkiResult.ThinClient from the “Solution Explorer” I have configured the database nicely as SkiResult.FullClient a WPF Project works fine and display data.
But whenever I have tried to run Silverlight project in my Solution Explorer it shows me following error message.
I have googled so much I have also found one solution that set xyz.WEB project as a Start Up Project but as u can see from below screenshot of my Solution Explorer there is no xyz.WEB project in solution.
Thank you so much.....
Try setting the SkiResult.DataService project to be the startup project. This looks very much a web project created to host a Silverlight application because:
it has a Web.config file (so it is clearly a web project)
it has a Silverlight.js file (some utility JavaScript used with Silverlight),
it has some autogenerated test pages,
it has a ClientBin folder, which is typically where the compiled Silverlight application will be copied to.
When you create a Silverlight project, Visual Studio offers to create a web application project to host the Silverlight application for you. (You don't have to create a web application - VS can generate a test webpage during the build process and use that instead.) If your Silverlight project is called Xyz, then this web application will be called Xyz.Web. However, with the solution you're dealing with above, it seems this project has been renamed from the default.
I'm using Visual Studio 2010 with the new website publish dialog. I have a Web Application website. When published, in theory it should compile all the code into an single assembly. However, in both Debug and Release, after publishing the directory always contains source code of page and user controls (even with the untransformed web.config files Web.Debug.config and Web.Release.Config). This is very confusing.
But with package/publish web project configuration and Generate Deploy package context menu item, the Package\PackageTmp directory is clean.
Why doesn't Visual Studio use this Package to publish the website?
Where is the precompile option?
Web.config xml transform seems not work, why does Visual Studio bring this feature to confuse me?
The correct answer is to look in the Package/Publish Web settings (in the web application project properties) and look for the "Items to deploy".
For a web application you'd want "Items to deploy" to have "Only files needed to run this application" which would NOT copy the source code files, since they've been compiled into the DLL in the bin folder.
Note that this setting varies for your current Build type (Debug/Release/etc), so plan accordingly...
Ciao!
You need to understand the differences between Web Application Projects versus Web Site Projects.
To deploy a Web application project, you copy the assembly that is
created by compiling the project to an IIS server. In contrast, to
deploy a Web site project, you typically copy the project source files
to an IIS server.
For Web application projects, you typically build the project in
Visual Studio or by using the ASP.NET batch compiler on a computer
that is not the production IIS server. All code-behind class files and
standalone class files in the project are compiled into a single
assembly, which is then put in the Web application project's Bin
folder. (The .aspx and .ascx files are compiled dynamically in a
manner similar to what is done for Web site projects.)
For Web site projects, you do not have to manually compile the
project. Web site projects are typically compiled dynamically by
ASP.NET (on both the development computer and the production IIS
server). You can choose between batch compilation mode, which
typically produces one assembly per folder, and fixed compilation
mode, which typically produces one assembly for each page or user
control.
In visual studio 2013/2015, select an option "Precompile during publishing"
I'm not sure if Visual Studio 2010 already does this or not with respect to how it packages Azure deployments, but I have a Visual Studio solution which contains 5 projects:
The Azure Service Project
The project for my web role
2 class library projects which
contain the DAL and BLL that my
roles use
And one MS Test project used for
unit and integration testing across
all of these projects
My deployment package right now is roughly 100 mbs, and takes a while to upload. I have some other things I can do to make it smaller, but what I want to know is if there's a way I can make sure that the MS Test project isn't being packaged alongside everything else given that it has the largest footprint. Any suggestions, or is this not actually a problem?
As long as there are no references from your web role, the DAL or BAL projects to the test project, then it shouldn't be included in the package.
If you're worried about it I would first of all double check all of the references in the web role, DAL and BLL projects to make sure that you're not accidentally referencing the test project.
As long as that is OK, I'd then do a publish of the project to disk and then have a poke around in the \bin directory if the cloud project to see what's actually using up all of that space.
Just as stated before is you do not have any references to your test project in your web role you should not worry for having it deployed alongside the rest of your code.
Another thing I would recommed is to just precompile your web site and
add it as another site in your file using a host header for it.
The advantage of that is that you can create a msbuild task to precompiled your site and just upload it.
Also I reposted about a solution for putting your view files in azure storage which will allow you to modify appearance without going thru the republish process.
http://blogs.artinsoft.net/mrojas/archive/2011/05/01/windows-azure-and-websites-in-a-flux.aspx